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1.0. 


INTRODUCTION 


This  technical  report,  prepared  by  the  Robotics  Division  of 
the  U.S.  Army  Tank-Automotive  Command  (TACOM) ,  describes 
communications  interoperability  (Cl)  between  different 
robotic  vehicle  systems,  and  also  different  robotic 
modules.  It  does  this  by  proposing  protocols  for  a 
communications  interface  standard  for  robotic  vehicle 
communication  systems. 

"Interoperability  is  critical  to  the  Army's  robotics 
program."1  Achieving  Cl  will  provide  three  major  benefits. 
The  first  is  the  more  effective  deployment  of  robotic 
systems.  The  second  is  the  significant  enhancement  of 
testing  and  demonstrations.  And  the  third  is  a  reduction 
in  the  cost  of  developing  and  building  these  systems. 


2.0.  OBJECTIVE 

The  primary  goal  was  to  propose  a  communications  interface 
standard,  consisting  of  a  set  of  protocols  and  a  unique 
message  format,  that  will  lead  to  Cl. 


3.0.  CONCLUSIONS 

This  study  offers  the  following  conclusions: 

•  The  development  and  adoption  of  a  communica¬ 
tion  interface  standard  is  a  better  approach 
to  Cl  than  the  use  of  translators. 

•  Now  is  a  good  time  to  develop  and  test  proto¬ 
cols  for  robotic  vehicle  communications 
because  many  robotic  systems  are  still  in  the 
testbed  stage. 

•  The  use  of  a  robotic  vehicle  communication 
subsystem  suggests  that: 

-  The  separation  of  the  video  imagery  from 
the  command  and  control  data  allows  the 
command  and  control  data  to  be  transmitted 
on  a  separate,  lower  frequency  carrier  in 
the  VHF  band.  There  are  advantages  to 
transmitting  in  this  band. 


1Captain  Rick  Lynch,  Program  review  at  TACOM, 
Warren,  Michigan,  23  October  1987 
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-  A  digital  communication  system  is 
superior  to  an  analog  one  for  the  command 
and  control  of  robotic  vehicles. 

•  A  simplified  versibh  of  Synchronous  Data  Link 
Control  (SDLC)  is  the  most  efficient  data 
link  layer  protocol. 

•  A  protocol  for  the  network  layer  is  not 
currently  needed,  but  may  be  added  at  a  later 
time* 

•  A  transport  layer  protocol  which  adds  a  two- 
byte  header  to  the  message  will  provide  the 
needed  transport  serVi6es. 

.*• 

e  A  block  message  foritfat,  developed  and  com¬ 
piled  in  this  report,  is  superior  to  a  fixed 
or  variable  length  ptessage  format  because: 

-  The  use  of  highTleVel  commands  allows 
for  the  ability  to  add  additional  commands 
and  the  capability  to  use  the  message  for 
any  application.  It  is  extremely  flexible 
and  will  not  become  obsolete. 

-  It  reduces  the  bandwidth  requirements  of 
a  communication  subsystem  on  a  complex 
robotic  vehicle. 

-  It  allows  for  the  use  of  commands  which 
can  be  ordered  by  priority. 

e  Automating  functions  is  a  way  of  reducing  the 
bandwidth  requirements  of  the  communication 
system. 


4.0.  RECOMMENDATIONS 

Based  on  the  results  of  this  investigation,  the  following 
recommendations  are  submitted: 

e  A  communication  interface  standard  should  be 
used  in  order  to  achieve  Cl. 

.  > 

e  The  protocols  and  message  format  proposed  in 
this  report  should  be  evaluated  and  tested 
for  application  to  robotic  vehicle  systems. 
Revisions  should  then  be  made  to  ensure  that 
optimum  protocols  are  available  for  systems 
that  will  be  fielded. 


•  For  a  robotic  vehicle  communication  sub¬ 
system: 

-  Video  imagery  and  command  and  control 
data  should  be  separated,  at  least  until 
practical  image  compression  becomes 
available.  The  command  and  control  data 
should  be  transmitted  in  the  VHP  band. 

-  Digital  communications  should  be  used. 

•  A  simplified  version  of  SDLC  should  be  used 
as  the  data  link  layer  protocol. 

•  A  block  message  format  should  be  used  to 
digitally  represent  the  control  commands  and 
the  status  information  that  passes  between  a 
control  station  and  an  RV. 

•  As  many  functions  on-board  the  robotic 
vehicle  as  possible  should  be  automated. 


5.0.  DISCUSSION 

5.1.  Interoperability 

5.1.1.  Standard  vs.  Translator.  Achieving 
interoperability  requires  one  of  two  approaches: 

•  Have  each  entity  talk  in  its  own  language,  and 
have  a  "translator"  interpret  the  language  it 
receives . 

•  Develop  and  adopt  a  communications  interface 
standard . 

Each  of  these  two  approaches  has  advantages.  Using  the 
translator  is  the  best  way  to  achieve  Cl  for  a  robotic 
vehicle  (RV)  system  that  has  already  been  built.  It  would 
be  costly  to  redesign  an  existing  system  so  that  it  would 
meet  a  standard's  specifications. 

Adopting  a  standard,  however,  is  a  better  approach  for 
systems  which  have  not  yet  been  built  because  it  is  more 
efficient,  and  it  will  result  in  cost  savings. 

Without  a  standard,  most  developers  will  design  their 
system  with  no  concern  for  communications  interoperability. 
Then  at  a  later  time  they  will  need  to  implement  a 
translator.  Designing  to  an  existing  standard  will  save 
time  and  money  down  the  road. 
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A  different  translator  would-  be  needed  for  every  system 
that  is  talked  to.  Also,  it  would  need  to  be  modified  with 
the  changes  in  functionality  of  every  vehicle. 

Using  a  standard  cuts  gut  one  step  in  the  communication 
propess.  With  the  translator,  there  is  a  "middle  man" 
between  the  two  entities  thm.t  are  communicating.  Using  a 
standard  allows  the  two  to  "speak"  directly  to  each  other. 

Building  a  communication  system  to  standard  specifications 
will  result  in  several  types  of  cost  savings.  The  first  is 
in  the  design  of  communication/control  subsystems.  Since 
the  communication  interface  to  be  used  will  be  described  in 
the  standard,  it  will  not  need  to  be  designed. 

The  second  savings  will  be  in  hardware  and  software  costs. 
All  communication  systems  adhering  to  the  standard  will 
have  common  hardware  and  software.  Once  the  software  is 
written  and  the  hardware  developed  for  one  system,  they  can 
be  used  at  minimal  cost  for  other  common  systems. 

Also,  the  best  way  to  keep  costs  down  is  through 
competitive  procurement.  To  achieve  the  cost  savings  of 
competitive  procurement,  and  to  get  the  highest  performance 
possible,  a  high  degree  of  compatibility  between . 
contractor's  subsystems  will  be  necessary*  Adoption  of  a 
communication  standard  will  provide  this  compatibility. 

5.1.2.  Background.  TACON  contacted  two  offices  to  deter¬ 
mine  if  a  standard  for  robotic  vehicle  communications  had 
already  been  developed:  1)  The  Interoperability  Network 
directorate  of  the  U.S.  Army  Communications-Electronics 
Command  (CECOM)  at  Fort  Monmouth,  New  Jersey,  which  has  the 
responsibility  of  making  Army  communication  equipment  com¬ 
patible.  2)  The  Joint  Tactical  C3  Agency  (JTC3A)  of  the 
Defense  Communications  Agency  (DCA)  in  Washington,  D.C., 
which  has  the  responsibility  of  ensuring  compatibility  of 
communication  equipment  in  the  joint  community  (all  the 
military  services).  This  investigation  yielded  no  stan¬ 
dard. 

There  are  three  other  Army  programs  which  address  inter¬ 
vehicle  communications.  ' 

•  Inter  Vehicle  Intercommunication  System 
(IVIS)  deals  with  digitally  transferring 
information  that  is  now  transferred  by  voice. 

It  is  an  Armor  School  concept  for  communica¬ 
ting  at  the  battaliqn  level  and  below.  It  is 
being  proposed  for  M1A1  Block  II. 

e  Combat  Vehicle  Command  and  Control  (CVC2)  is 
the  next  generation  iyiS.  It  provides  for 


the  networking  of  vehicles  at  the  individual 
vehicle,  platoon,  company  and  battalion  com¬ 
mander  echelons.  CVC2  applies  to  M1A1,  Brad¬ 
ley,  and  future  combat  vehicles. 

•  Battlefield  Management  System  (BMS)  is  the 
networking  of  all  assets  at  battalion  level 
and  below. 

These  three  programs  are  in  the  very  early  stages.  At  this 
point  it  is  difficult  to  speculate  how  robotic  vehicle 
communication  systems  will  be  affected  by  these  programs, 
which  are  targeted  for  manned  vehicles. 

Most  likely  there  will  be  commonality  between  the  robotic 
vehicle  communication  standard  and  these  other  battlefield 
communication  techniques.  But  robotic  vehicle  communica¬ 
tion  needs  are  unique  in  some  ways  and  thus  should  be 
addressed. 

5.1.3.  Communications  Interface  Standard.  The  standard 
must  completely  describe: 

•  The  information  -  its  structure,  format,  and 
meaning. 

•  The  communication  system  -  the  hardware, 
protocols,  and  signals  used  to  transfer  the 
information. 

This  report  will  describe  and  use  the  Open  Systems  Interco¬ 
nnection  Reference  Model  (OSI-RM)  as  a  means  of  discussing 
the  issues  involved  in  the  development  of  a  standard  inter¬ 
face  document.  Before  further  discussing  the  OSI-RM,  how¬ 
ever,  it  is  important  to  clarify  what  needs  to  be  communi¬ 
cated  by  these  subsystems,  what  portion  of  those  communica¬ 
tions  will  be  addressed  in  this  report,  and  what  format 
(digital  or  analog)  the  communication  system  should  use. 

5.1.4.  Communication  Needs.  A  robotic  vehicle  system 
communication  subsystem  provides  for  continuous,  bidirec¬ 
tional  communications  between  a  control  station  and  one  or 
more  RVs.  From  a  control  station  to  an  RV,  the  subsystem 
provides  for  the  transmission  of  signals  generated  at  the 
control  station  which  control  the  functions  of  the  RV 
(movement,  weaponry,  etc.). 

From  an  RV  to  a  control  station,  the  subsystem  provides  for  the 
transmission  of  signals  which  allow  the  remote  operator 
located  in  the  control  station  to  effectively  operate  the 
RV.  These  signals  depict  the  status  of  the  RV  and  its 
subsystems.  Also,  video  and  other  sensory  information 
captured  by  cameras  and  other  sensors  aboard  the  RV  are 
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needed. 


5.1.5.  Communication  Portion  Addressed.  Robotic  vehicle 
systems  need  to  maintain  continuous  communications  to  avoid 
a  control  statidn  losing  control  of  its  RVs.  The  ability 
to  do  so  is  hindered  dite  to  spectrum  jamming,  natural 
electromagnetic  interference  (EMI),  signal  attenuation,  and 
foliage  and  terrain  blocking  the  line  of  sight  (LOS)  path 
between  the  two  communicating  vehicles. 

The  communicating  medium  can  be  either  hardwired  (fiber 
optic  cable,  coaxial  cable)  or  softwired  (radio  communica¬ 
tions).  For  radio  communications,  there  are  specific 
advantages  to  transmitting  at  lower  frequencies  (VHF  or 
UHF)  as  opposed  to  higher  fr&cj$iencies.  See  Table  5-1  for  a 
designation  of  the  frequencies. 

These  advantages  include: 

•  The  ability  to  penetrate  foliage  and  other 
obstructions  increases  as  frequency 
decreases.  (See  Figure  5-1) 

•  As  frequency  decreases,  signal  attenuation 
decreases. 

•  Simple  antennas  can  be  used  instead  of  com¬ 
plex  arrays. 

An  obstacle  to  using  the  lower  frequency  bands  is  the  lack 
of  available  frequency  bandwidth.  Using  current  tech¬ 
nology,  about  6  MHz  of  bandwidth  are  required  for  a  single 
FM-modulated  video  channel.  For  an  RV  with  four  video 
channels,  bandwidth  needed  would  be  a  minimum  of  36  MHz. 

Currently,  there  are  no  VHF  or  UHF  bands  allocated  for  an 
application  requiring  so  much  bandwidth.  The  existing 
bands  are  extremely  congested  with  both  military  and  com¬ 
mercial  users,  and  it  is  unlikely  that  any  bands  will 
become  available.  Therefore  the  video  imagery  will  need  to 
be  transmitted  in  the  higher  frequency  ranges,  at  least 
until  practical  image  compression  techniques  become  avail¬ 
able.  Once  practical  compression  techniques  become  avail¬ 
able,  it  will  be  possible  to  transmit  video  in  a  VHF  or  UHF 
band. 

The  command  and  control  information  requires  far  less 
bandwidth  than  uncompressed  Video.  The  exact  bandwidth 
required  is  yet  to  be  detenA ind&,  but  it  is  in  the  range  of 
5-100  kHz.  This  is  narrow  enough  to  be  placed  in  a  VHF  or 
UHF  band.  Therefore,  it  is  advantageous  to  separate  the 
video  information  from  the  command  and  control  information, 
transmitting  the  video  channels  in  the  microwave  band  or 
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Table  5-1.  Designation  of  Electromagnetic  Waves 


Frequency  Band 

Designation 

3-30  kHz 

Very  low  frequency  (VLF) 

30  -  300  kHz 

Low  frequency  (LF) 

300  -  3000  kHz 

Medium  frequency  (MF) 

3-30  MHz 

High  frequency  (HF) 

30  -  300  MHz 

Very  high  frequency  (VHF) 

300  -  3000  MHz 

Ultrahigh  frequency  (UHF) 

3-30  GHz 

Superhigh  frequency  (SHF) 

30  -  300  GHz 

Extremely  high  frequency  (EHF) 

NOTE:  500  MHz  -  40  GHz  is  also  designated  as  the 

microwave  band. 

15 


foliage 


higher,  and  the  command  and  control  channels  in  the  VHF  or 
UHF  band.  Command  of  the  RV  can  be  maintained  even  as  the 
video  picture  fades  out. 

The  rest  of  this  report  will  deal  only  with  compatibility 
for  the  transmission  of  command  and  control  information. 

It  will  not  deal  with  compatibility  for  the  transmission  of 
video  and  other  sensory  imagery. 

5.1.6.  Digital  Versus  Analog.  Command  and  control  signals 
can  have  one  of  two  representations,  either  digital  or 
analog.  Both  systems  have  advantages. 

5. 1.6.1.  Digital  advantages. 

•  Good  performance  is  possible  with  a  signal- 
to-noise  ratio  of  only  20  to  30  decibels 
(dB).  A  frequency-modulated  analog  system 
would  require  30-40  dB  for  similar  quality, 
and  an  amplitude-modulated  analog  signal  an 
even  higher  signal-to-noise  ratio. 

•  Works  well  with  systems  requiring  the  data  to 
be  relayed  over  multiple  hops,  because  the 
digital  information  is  regenerated  at  each 
relay.  This  is  in  contrast  to  an  analog  sys¬ 
tem,  where  the  noise  and  distortions  are  not 
simply  those  of  the  weakest  link,  but  those 
of  the  accumulation  of  all  the  relays. 

a  Error  control  techniques  can  be  used  to 
detect  and/or  correct  most  bit  errors. 

•  Most  encryption  techniques  are  discrete  in 
nature,  allowing  for  data  security. 

•  Transparent  to  the  type  of  data.  The  signal 
could  be  voice,  video,  or  computer  data  and 
any  user  with  a  compatible  digital  interface 
could  receive  the  information.  For  analog 
systems,  channels  must  be  modeled  according 
to  the  nature  of  the  signal. 

•  A  higher  capacity  per  carrier  frequency  can 
be  accommodated,  using  a  time  division 
multiple  access  (TDMA)  technique.  TDMA  is  a 
more  efficient  multiplexing  technique  than 
frequency  division  multiplexing  (FDM) ,  which 
is  used  with  analog  systems. 

5. 1.6. 2.  Analog  advantage.  Most  sensors  have  an  analog 
output.  To  use  a  digital  system-  an  analog-to-digital 
(A/D)  conversion  must  take  place.  This  process  increases 
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system  complexity  and  cost.  It  also  can  introduce  a 
quantization  error. 

5. 1.6. 3.  Preferred  Signal  Representation.  A  digital 
system  is  superior  to  an  analog  system  for  the  robotic 
vehicle  communications  application  because  of: 

•  Superior  performance  with  the  same  signal-to- 
noise  ratio 

•  Superior  performance  over  multiple  hops 

•  Available  error  control  techniques 

•  Compatibility  with  encryption  techniques 

•  Transparency  to  the  type  of  data 

•  Higher  capacity  per  carrier 

The  rest  of  this  chapter  will  deal  only  with  digital  data 
communications . 

5.1.7.  The  OSI  Reference  Model. 

§. 1.7.1.  Introduction.  The  International  Organization  for 
Standardization  (ISO)  is  a  voluntary  organization  formed  to 
make  standards.  TC97,  one  of  ISO's  technical  committees, 
is  concerned  with  informatioh  systems.  TC97  developed,  and 
in  1978  ISO  introduced,  the  Open  Systems  Interconnection 
Reference  Model  (OSI-RM) . 

The  OSI-RM  is  a  model  of  a  computer  communications 
architecture.  It  was  developed  to  promote  compatible  com¬ 
munications  among  a  wide  variety  of  digital  systems.  It  is 
a  framework  for  developing  Standards,  and  it  provides  the 
terms  of  reference  for  discussing  communication  system 
design.  It  has  succeeded  in  winning  general  acceptance  in 
the  telecommunication  industry,  and  therefore  will  be 
applied  to  the  problem  of  robotic  vehicle  system's  communi¬ 
cation  compatibility. 

5. 1.7. 2.  Description.  The  OSI-RM  is  not  a  protocol 
standard.  Instead,  it  specifies  seven  distinct  layers  that 
define  the  functions  involved  in  communicating.  To 
implement  the  OSI-RM,  protocols  have  been  and  are  being 
developed  and  standardized  at  each  layer. 

One  advantage  of  the  OSI-RM  is  that  all  the  layers  are 
modular.  This  allows  different  groups  to  develop  protocols 
at  different  layers  with  some  assurance  that  the  various 
layers  can  work  together  in  a  system.  Modularity  also 
permits  the  existence  of  sublayers,  meaning  multiple  proto- 
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cols  at  each  layer. 

Each  layer  must  communicate  with  the  layer  above  and  below 
it.  They  must  follow  rules  for  these  interlayer 
interfaces. 

For  communicating  between  entities,  it  is  imperative  that 
all  the  entities  have  identical  layers  and  use  the  same 
protocols. 

The  OSI-RM  is  shown  in  Figure  5-2.  It  ranges  from  the 
medium,  to  the  Physical  (lowest)  Layer,  and  up  through  the 
Application  (highest)  Layer. 

The  bottom  three  layers  are  communication  layers,  concerned 
with  the  transmission  of  bits  and  bytes.  These  layers  are 
hardware  dominated.  The  top  three  layers  are  the  informa¬ 
tion  processing  layers,  adding  intelligence  to  the  bits 
and  bytes  which  will  be  or  have  been  transmitted.  These 
layers  are  software  dominated.  The  fourth,  or  middle 
layer,  bridges  the  gap  between  these  two  sets  of  layers. 

The  following  sections  describe  the  medium  and  each  layer 
in  some  detail. 

•  The  Medium.  The  medium  refers  to  the  type  of 
channel  over  which  the  signal  is  transmitted. 

Some  possibilities  include: 

-  Air 

-  Twisted  pair  wire 

-  Coaxial  cable 

-  Fiber  optic  cable 

-  Water 

-  Laser 

•  The  Physical  Layer.  The  physical  layer  is 
the  bottom,  and  first,  layer  of  the  OSI-RM. 

Its  responsibility  is  to  send  and  receive 
bits  over  the  medium.  It  covers  the  physical 
interface  between  devices  and  the  rules  by 
which  bits  are  sent  and  received.  This  layer 
is  concerned  with  the  following  functions: 

-  Matching  the  physical  medium. 

-  Channel  encoding  the  data. 
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-  Sequencing  of  events  for  transmitting  data. 

-  Physically  connecting  the  devices. 

-  Modulating  and  demodulating  the  signals. 

The  Data  Link  Layer.  The  data  link  layer  is 
the  second  layer  of  the  OSI-RM.  It  attempts 
to  make  the  physical  layer  reliable.  It 
performs  the  following  functions: 

-  Link  management  -  activation,  mainte¬ 
nance,  and  deactivation  of  the  link. 

-  Error  control  -  bit  error  detection 
and/or  correction. 

-  Flow  control  -  does  not  allow  a  fast 
sender  to  clobber  a  slow  receiver. 

-  Synchronization  -  synchronizes  the  sen¬ 
der  and  the  receiver  that  are  exchanging 
data. 

-  Addressing  -  identifies  the  sender 
and/or  receiver  of  the  data. 

To  perform  these  functions,  the  bits  are 
arranged  into  frames.  The  frames  add  over¬ 
head  bits,  which  are  used  to  perform  the 
functions  of  this  layer.  These  frames  are 
passed  down  to  the  physical  layer  for  trans¬ 
mission.  The  layer  above  the  data  link  layer 
can  assume  error  free  data  because  the  trans¬ 
mission  errors  have  been  corrected  by  this 
layer. 

The  Network  Layer.  The  third  layer  is  the 
network  layer.  The  network  layer  routes  data 
through  a  network  of  computers/terminals.  It 
relieves  the  upper  layers  of  the  need  to  know 
anything  about  the  methodology  used  to  estab¬ 
lish  the  connection  between  the  end  entities. 

It  also  allows  the  lower  two  layers  to  deal 
only  with  point  to  point  communications. 

It  does  this  by  organizing  the  data  into 
packets.  Packets  are  the  frames  from  the 
datci  link  layer  with,  additional  overhead 
added . 

The  Transport  Layer.  The  transport  layer  is 


the  fourth,  arid  middle,  layer.  It  is  the 
bridge  between  the  three  lower  communications 
layers  and  the  three  higher  information  pro¬ 
cessing  layers.  The  transport  layer  is  re¬ 
sponsible  for  end-to-end  (originating  source 
to  ultimate  destination)  services.  These 
services  include  flow  control,  error  control, 
sequencing,  survival  of  the  connection,  and 
expedited  delivery. 

The  transport  layer  does  for  an  end-to-end 
link  (including  relays  and  repeaters)  what 
the  data  link  layer  does  for  point-to-point 
links.  It  performs  these  functions  by  assem¬ 
bling  the  data  into  transport  protocol  data 
units  (TPDU) .  The  TPDUs  add  overhead  bits, 
which  are  used  to  perform  the  functions  of 
this  layer. 

e  The  Session  Layer.  The  fifth  layer  is  the 
session  layer.  The  session  layer  provides 
the  mechanism  for  controlling  the  dialogue 
between  applications.  It  can  do  the  follow¬ 
ing: 

-  Establish  and  terminate  connections. 

-  Provide  one  of  three  types  of  dialogue: 
full-duplex,  half-duplex,  or  simplex. 

-  Allow  either  abrupt  or  graceful  discon¬ 
nections,  meaning  a  message  can  or  can 
not  he  disrupted  in  the  midst  of  a 
transmission,  and  also  what  to  do  if  the 
message  is  interrupted. 

e  The  Presentation  Layer.  The  presentation 
layer  is  the  sixth  layer.  The  presentation 
layer  ensures  that  information  is  delivered 
in  a  form  that  the  receiving  system  can  un¬ 
derstand.  Its  purpose  is  to  resolve  differ¬ 
ences  in  format  and  data  representation  by 
defining  the  syntax  used. 

Security  through  encryption,  message  compres¬ 
sion,  and  syntax  conversion  can  also  be  done 
at  this  layer. 

e  The  Application  Layer.  The  application  layer 
is  the  seventh,  and  tbj),  layer.  It  serves  as 
a  window  between  the  application  process  and 
the  OSI  communications  environment.  This 
lav«r  manipulates  information  and  manages 
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5. 1.7. 3 


resources  to  support  distributed  applica¬ 
tions.  To  the  user,  this  layer  appears  to  be 
doing  the  real  work. 

Application  of  the  OSI-RM. 

•  The  Physical  Layer.  There  are  a  variety  of 
standard  protocols  for  the  physical  layer 
which  define  all  the  functions  for  this 
layer.  The  most  popular  are: 

-  RS-232-C 

-  RS-4 4 9/4 2 2 -A/4 2 3 -A 

-  CCITT  X.21 

All  three  provide  the  necessary  mechanical, 
electrical,  functional,  and  procedural  speci¬ 
fications. 

RS-232-C  is  the  oldest  and  most  widely  used 
of  the  interface  standards. 

The  RS-449/422-A/423-A  set  of  protocols  was 
designed  specifically  to  replace  the  RS-232- 
C.  It  provides  performance  advantages  over 
the  RS-232-C  in  the  areas  of  achievable 
transmission  distances,  speed  characteris¬ 
tics,  and  modem  control.  While  the  RS-232-C 
remains  the  most  popular  interface  protocol, 
the  RS-4 4 9/4 2 2 -A/4 2 3 -A  set  is  experiencing 
increasing  growth  in  usage. 

X.21  is  the  newest  and  thus  far  the  least 
used  of  the  three  protocols.  It  provides 
fewer  circuits  (pin  connections)  than  the 
other  two  protocols,  but  adds  more  logic. 

With  the  falling  cost  of  logic  circuitry, 
this  can  be  an  advantageous  approach. 

X.21  provides  the  same  speed  characteristics 
and  transmission  distances  as  the  RS-449/422- 
A/423-A  set  of  protocols.  It  is  also  more 
flexible  and  potentially  less  costly. 

Choosing  the  optimum  physical  layer  protocol 
will  involve  weighing  the  following  advan¬ 
tages  against  each  other: 

-  The  extremely  wide-spread  use  of  the  RS- 
232-C. 
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-  The  improved  performance  and  growing  use 
Of  the  RS-449/422-A/423-A. 

-  The  strong  performance,  flexibility,  and 
potential  cost  savings  of  the  X.2.1, 

The  analysis  of  these  thr&e  protocols  and  the 
choice  of  an  optimum  one  for  robotic  vehicle 
systems  is  outside  the  scope  of  this  report. 

•  The  Data  Link  Layer.  To  perform  the  func- 
tions  of  the  data  link  layer,  overhead  bits 
are  added  to  the  data  bits  and  arranged  into 
frames.  An  optimum  frame  format  is  one  which 
can  effectively  perforin  the  needed  functions, 
and  do  so  with  the  minimum  number  of  overhead 
bits.  A  minimum  number  of  overhead  bits  is 
desired  because  as  the  overhead  goes  up,  the 
amount  of  data  that  can  be  transmitted  drops, 
assuming  constant  bandwidth. 

The  functions  needed  at  the  data  link  layer 
for  robotic  vehicle  systems  are: 

-  Synchronization 

-  Vehicle  addressing 

-  Error  control 

Synchronization  refers  to  the  ability  of  the 
receiving  entity  to  determine  when  a  signal 
being  transmitted  to  it  starts  and  ends. 

This  is  usually  done  using  some  type  of  flag. 

Vehicle  addressing  refers  to  the  ability  of  a 
control  station  to  transmit  information  to 
the  RV  it  intends  to*  When  there  is  a  one- 
to-one  control-station-to-RV  ratio,  as  with 
current  robotic  vehicle  systems,  this  is  not 
necessary.  Also,  if  each  vehicle  is  con¬ 
trolled  over  a  different  channel,  as  with 
near  term  systems,  it  is  unnecessary.  But 
for  far  term  systems,  when  one  control  sta¬ 
tion  will  be  supervising  multiple  RVs,  an 
addressing  scheme  will  be  necessary. 

Error  control  is  the  ability  of  the  receiving 
entity  to  detect  and  either  correct  or  disre¬ 
gard  data  frames  that  iave  been  damaged  (con¬ 
tain  erroneous  bits)  during  transmission. 

There  are  a  variety  of  standard  protocols 
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which  perforin  these  necessary  functions. 

Some  of  the  more  widely  used  ones  are: 

-  High-level  data  link  control  (HDLC) 

-  Synchronous  data  link  control  (SDLC) 

-  Digital  data  control  message  protocol 
(DD  CMP) 

-  IEEE  802.3 

HDLC  and  SDLC  are  virtually  identical,  and 
thus  will  be  treated  as  one  protocol. 

In  addition,  there  are  many  nonstandard  data 
link  layer  protocols  used  by  communication 
systems . 

Using  a  standard  protocol  offers  the  advan¬ 
tage  of  using  already  developed  and  available 
communications  controller  hardware.  There¬ 
fore  the  protocol  proposed  will  be  an  exist¬ 
ing  standard. 

Choosing  the  standard  will  be  done  by  deter¬ 
mining  which  protocol  performs  the  needed 
functions  in  a  satisfactory  manner  with  the 
minimum  overhead.  This  can  be  done  by  exam¬ 
ining  the  frame  format  of  each  protocol  men¬ 
tioned  above.  The  different  frame  formats 
are  shown  in  Figure  5-3.  Table  5-2  shows  a 
comparison  of  the  different  protocols. 

As  shown,  HDLC/ SDLC  has  the  least  overhead 
bits  per  frame  and  also  allows  for  a  large 
number  of  data  bytes  to  be  transmitted  in 
each  frame.  Therefore,  it  is  the  most  effi¬ 
cient. 

For  robotic  vehicle  systems,  a  simplified 
version  of  the  SDLC  protocol  is  proposed. 

(See  Figure  5-4.)  This  protocol  provides  all 
the  needed  functions. 

•  Network  Layer.  The  network  layer  routes  data 
through  a  network  of  communicating  entities. 
For  current  robotic  vehicle  system  applica¬ 
tions,  all  communications  are  simple  point  to 
point  (control  station  directly  to  RV). 
Therefore,  no  protocol  is  needed  for  this 
layer. 
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Figure  5-3,  Frame  Formats 
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Table  5-2.  Data  Link  Layer  Protocols 


Protocol 

Synchron¬ 

ization 

Vehicle 

Address 

Error 

Control 

Overhead 

Bits/frame 

Data  Bytes/ 
Frame 

HDLC/ 

SDLC 

Yes 

Yes 

Yes 

48 

Any  number 
of  bytes 

B3 

Yes 

Yes 

Yes 

98 

1-16,383 

IEEE  802.3 

Yes 

Yes 

Yes 

208 

64-1518 
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Flag 

Address 

Data 

CRC 

Flag 

RCC 

RV 

01111110 

3  bits 

5  bits 

o  bits 

16  bits 

01111110 

Figure  5-4.  Simplified  SOLC  Frame  Format 
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As  robotic  vehicle  systems  become  more  intel¬ 
ligent,  however,  they  will  need  to  cooperate 
and  thus  should  be  networked  together.  Also, 
using  an  RV  that  is  in  the  line-of-sight  of 
the  control  station  as  a  signal  repeater  is 
one  way  to  maintain  a  data  link  with  other 
RVs  that  are  not  in  the  line-of-sight  of  the 
control  station. 

Due  to  the  modular  nature  of  standards 
developed  using  the  OSI-RM,  a  network  layer 
protocol  may  be  added  at  a  later  time  without 
affecting  the  protocols  at  the  other  layers. 

Transport  Layer.  The  transport  layer  makes 
end-to-end  transmissions  reliable.  It  does 
for  a  multihop  network  what  the  data  link 
layer  does  for  point-to-point  communications. 

Since  currently  we  are  only  dealing  with  a 
direct  data  link  between  the  control  station 
and  the  RV,  some  of  the  transport  layer  ser¬ 
vices  are  not  needed.  The  following  services 
are  needed: 

-  Sequencing 

-  Expedited  delivery 

-  Survival  of  the  connection 

Transport  Protocol  Data  Units.  These  ser¬ 
vices  are  provided  by  assembling  the  data 
into  TPDUs.  For  robotic  vehicle  systems,  a 
TPDU  consisting  of  a  two-byte  header  added  to 
the  message  received  from  the  upper  layers  is 
proposed . 

The  first  header  byte  is  the  data  unit  code. 
The  second  header  byte  is  the  sequence 
number. 

TPDU  Types.  There  are  three  types  of  TPDUs: 

-  Information  packet 

-  Acknowledgement  packet 

-  Blank  packet 

Information  Packets.  An  information  packet 
carries  the  message  from  the  higher  layer. 
There  are  six  different  types  of  information 
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packets s 

-  Normal  data  (ND).  Has  the  lowest  pri¬ 
ority.  Will  be  sent  last  when  expedited 
or  express-type  packets  are  waiting  to 
be  sent. 

-  Expedited  data  (ED).  Has  middle  priori¬ 
ty.  Will  be  sent  before  normal  but 
after  express  data. 

-  Express  data  (XD).  Has  the  highest 
priority.  Will  be  sent  before  any  other 
packet  type. 

-  Normal  data  with  acknowledgement  (NA). 
Lowest  priority  but  requires  an  acknowl¬ 
edgement. 

-  Expedited  data  with  acknowledgement 
(EA).  Middle  priority  with  acknowledge¬ 
ment  required. 

-  Express  data  with  acknowledgement  (XA). 
Highest  priority  with  acknowledgement 
required. 

Acknowledgements  Packets.  An  acknowledgement 
packet  is  used  when  the  receipt  of  an  infor¬ 
mation  packet  requires  an  acknowledgement. 
Only  positive  acknowledgements  are  provided. 
If  a  positive  acknowledgement  is  not  received 
before  the  transport  timer  expires,  the  soft¬ 
ware  treats  it  as  tfte  negative  acknowledge¬ 
ment  of  an  information  packet.  A  125-ms 
timer  is  proposed. 

There  are  three  types  of  acknowledgements: 

-  Positive  acknowledgement  for  normal 
data  (ACK) 

-  Positive  acknowledgement  for  expe¬ 
dited  data  (ECK) 

-  Positive  acknowledgement  for  express 
data  (XCK) 

Blank  Packets.  Blank  packets  are  used  to  let 
the  other  side  know  that  the  communication 
link  is  still  up  even  though  there  is  no 
information  to  be  sent.  A  blank  packet  is 
sent  when  the  transport  has  nothing  to  send 
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for  200  ms.  When  nothing  has  been  received 
for  three  cycles  (600  ms),  an  alarm  message 
is  sent  to  the  appropriate  application  soft¬ 
ware  saying  that  there  is  something  wrong 
with  the  communication  link. 

Data  Unit  Codes.  Table  5-3  has  a  list  of  the 
data  unit  codes. 

Sequence  Number.  Each  packet  is  numbered 
sequentially.  Since  it  is  a  one  byte  number, 

256  (28)  TPDUs  can  be  numbered  before  start¬ 
ing  over. 

TPDU  Lengths.  Each  information  packet  has 
the  two  byte  header  followed  by  a  data  field 
of  unlimited  length.  An  acknowledgement 
packet  has  a  total  length  of  three  bytes,  the 
two  byte  header  and  the  sequence  number  of 
the  received  information  packet  to  be  acknow¬ 
ledged.  A  blank  packet  consists  of  only  the 
two  byte  header. 

•  Session  Layer.  The  session  layer  can  be 

rather  lean  due  to  the  simple  point  to  point 
communications.  One  issue  that  can  be  set¬ 
tled  at  this  layer  is  the  dialogue  type. 

There  are  three  dialogue  types: 

-  Simplex:  can  transmit  only  in  one  direction. 

-  Half-duplex:  can  transmit  in  both  directions, 
but  only  one  at  a  time. 

-  Full-duplex:  can  transmit  in  both  directions 
simultaneously . 

For  maintaining  effective,  real-time  control 
of  an  RV,  many  of  the  control  signals  from 
the  control  station  and  status  signals  from 
the  RV  must  be  relayed  as  soon  as  they  are 
av<iilable  for  transmission.  This  requirement 
warrants  the  use  of  full-duplex  communica¬ 
tions  . 

Another  issue  that  should  be  discussed  at 
this  layer  is  the  type  of  disconnection, 
either  graceful  or  abrupt,  that  should  be 
emiployed.  With  a  graceful  disconnection,  a 
message  that  is  cut  off  before  it  is  com¬ 
pletely  transferred  will  be  retransmitted  as 
soon  as  the  resources  to  do  so  are  available. 
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Table  5-3.  Data  Unit  Codes 


TYPE 

DATA  UNIT 

CODE 

Information 

Packet 

ND 

ED 

XD 

0000  0010 

NA 

0000  0100 

EA 

0000  0101 

XA 

Acknowledg¬ 
ment  packet 

ACK 

ECK 

BOI 

XCK 

Blank  Packet 

BLNK 
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With  an  abrupt  disconnection,  the  message 
that  is  not  completely  transferred  is  ig¬ 
nored. 

The  need  for  graceful  disconnections  arises 
from  systems  exchanging  large  amounts  of 
data,  such  as  file  transfers,  with  no  time 
restriction.  In  contrast,  controlling  a 
robotic  vehicle  requires  many  short  command 
and  status  messages.  Because  of  this, 
retransmission  of  cut  off  messages  is  not 
required.  Therefore  abrupt  disconnections 
are  proposed. 

•  The  Presentation  Layer.  For  robotic  vehicle 
communication  system  applications,  the  pre¬ 
sentation  layer  must  provide  for  security  and 
must  describe  the  bit  and  byte  representa¬ 
tions  of  the  control  commands  and  the  status 
information.  Current  and  very  near  term 
robotic  vehicle  systems  are  primarily  tech¬ 
nology  demonstrators,  and  thus  do  not  require 
data  security.  Future  fielded  systems,  as 
well  as  mid  and  far  term  demonstrators,  will 
require  security,  and  this  can  be  provided  by 
an  encryption  sub-layer  of  the  presentation 
layer.  Addition  at  a  later  date  of  this  sub¬ 
layer  is  possible  due  to  the  modular  nature 
of  the  OSI-RM. 

Description  of  the  bit  and  byte  representa¬ 
tions  of  the  control  commands  and  the  status 
information  can  be  achieved  by  the  develop¬ 
ment  and  implementation  of  a  robotic  vehicle 
message  format.  The  development  of  a  message 
format  for  this  purpose  is  detailed  in  sec¬ 
tions  5.2  and  5.3. 

Application  Layer.  The  application  layer 
takes  care  of  functions  such  as  file  trans¬ 
fers,  graphics,  data  base  management,  etc. 

Proposing  protocols  for  this  layer  is  out  of 
the  scope  of  this  report. 

5.2.  Robotic  Vehicle  System  Functions 

5.2.1.  Introduction.  A  message  format  describes  the  bit 
and  byte  representations  of  the  control  commands  and  status 
information  used  by  a  robotic  vehicle  system.  A  message 
format  is  part  of  the  Presentation  layer  of  the  OSI-RM,  as 
described  in  the  previous  section. 

The  development  of  a  message  format  can  be  broken  down  into 


33 


two  main  tasks? 

Compilation  of  the  control  functions  and  status 
information  required  to  remotely  operate  a 
vehicle. 

A  method  of  representing  the  compiled  information. 

This  section  will  address  the  first  task,  that  of  compiling 
the  information  needed  to  remotely  control  a  vehicle.  The 
objective  is  to  make  the  compilation  as  comprehensive  as 
possible  so  that  the  message  format  can  be  used  by  any  and 
all  military  robotic  vehicle  systems,  both  now  and  in  the 
future,  performing  a  wide  vai^e^Y  of  missions. 

5.2.2.  Manned  Military  Vehicles.  Operating  a  vehicle 
remotely  requires  performing,  at  a  remote  location,  the 
operations  normally  performed  by  a  crew  within  the  vehicle. 
To  begin  compiling  a  list  of  all  the  control  commands  and 
status  information  necessary  to  remotely  control  a  vehicle, 
the  operation  of  current  manned  vehicles  can  be  studied. 

5.2.2. 1.  Vehicles  studied.  For  this  study,  four  vehicles 
were  chosen: 

M1A1  Abrams  Main  Battle  Tank 
M2/M3  Bradley  Fighting  Vehicle 

High  Mobility  Multipurpose  Wheeled  Vehicle  (HMMWV) 

ACEC  Cobra 

These  four  particular  vehicles  were  chosen  for  two  reasons: 

e  All  are  state-of-the-art  vehicles,  recognized 
as  performance  leaders  in  their  individual 
fields. 

<: 

•  They  represent  a  good  cross  section  of 
military  vehicles. 

-  They  represent  the  three  general  weight 
classes  of  vehicles: 

Heavy  -  M1A1 

Medium  -  M2/M3,  Cobra 

■t  *  ‘ 

Light  -  HM^WV, 

-  Three  are  tracked,  one  is  wheeled  (the 
HMMWV) . 
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-  Three  are  diesel  powered,  one  is  turbine 
powered  (the  M1A1). 

-  Three  have  mechanical  transmissions,  one 
has  electric  drive  (the  Cobra). 

By  studying  four  vehicles  which  are  significantly  different 
in  design,  a  more  complete  list  of  control  commands  and 
status  information  which  will  be  required  on  future  robotic 
vehicle  systems  performing  a  wide  variety  of  missions  can 
be  obtained.  Appendix  A  gives  the  results  of  the  survey  of 
the  four  vehicles. 

5.2.3.  Unmanned  Vehicle  Systems.  Compiling  a  list  of 
functions  and  status  information  needed  for  robotic  vehicle 
systems  can  be  aided  by  studying  current  robotic  vehicle 
systems  and  learning  from  what  has  already  been  done.  This 
was  done  with  systems  developed  or  under  development  by  the 
six  organizations  listed  in  Table  5-4. 

These  systems  were  studied,  but  the  documents  describing 
the  systems  will  not  be  included  in  this  report  because  of 
the  competitive  situation  these  companies  are  in. 

5.2.4.  Additional  Functions.  Surveying  current  manned  and 
unmanned  military  vehicles  was  very  helpful  in  compiling  a 
control/ status  listing.  But  future  vehicles  will  continue 
to  change  and  progress,  and  will  have  additional 
requirements  for  command  and  control. 

To  predict  requirements  of  future  systems,  a  series  of 
meetings  was  held  with  personnel  from  TACOM's  Robotics 
Division.  At  these  meetings,  additional  controls  and 
status  were  discussed  and  compiled. 

5.2.5.  Higher  Level  Control  Commands.  Surveying  the  four 
manned  vehicles  has  led  to  an  accumulation  of  low-level 
commands  required  to  control  a  vehicle.  Likewise,  the 
Grumman,  Kaman,  and  Sandia  systems  were  completely 
teleoperated,  thus  accumulating  more  low-level  vehicle 
control  commands. 

5. 2. 5.1-  RV  intelligence.  The  commands  required  to 
control  an  RV  vary  greatly  with  the  intelligence  of  the 
vehicle.  Robotic  vehicle  system  developers  are  working  to 
continually  increase  the  intelligence  of  their  RVs. 

When  RVs  lack  intelligence,  they  require  many  explicit  low 
level  directions  on  what  to  do  and  on  how  to  do  it.  As  RVs 
gain  intelligence,  a  smaller  quantity  of  high  level 
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Table  5-4.  Robotic  Vehicles  Studied 


r  - \ 

®  FMC  Corporation 

9  General  Dynamics  Land  Systems 

0  General  Motors  Deice 

9  Grumman  Corporation 

Kaman  Sciences  Corporation 

9  Sandia  National  Laboratories 

k  .  ■  '  - .  . . > 
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commands  can  be  substituted  for  the  many  low  level 
commands . 

5. 2. 5. 2.  Autonomy.  An  increase  in  onboard  RV  intelligence 
means  the  vehicle  has  become  more  autonomous.  An  RV  with 
increased  autonomy  is  desired  for  two  reasons: 

1.  The  RV  to  control  stations  data  link  has  a 
decreased  bandwidth  requirement. 

2.  Workload  of  RV  operator  is  decreased. 

•  Decreased  Bandwidth  Requirement.  Inter¬ 
vehicle  communications  on  the  battlefield  are 
hindered  by  enemy  electromagnetic  warfare,  as 
well  as  by  natural  obstacles  (hills,  trees, 
foliage)  and  natural  electromagnetic  inter¬ 
ference.  The  greater  the  amount  of  informa¬ 
tion  needed  to  be  transmitted,  the  greater 
the  bandwidth  requirement  of  the  communica¬ 
tion  system,  and  the  more  difficult  it  is  to 
successfully  transfer  the  data. 

Conversely,  the  less  information  that  must  be 
transmitted,  the  smaller  the  bandwidth  re¬ 
quirement  of  the  communication  system,  and 
the  capability  to  successfully  transfer  the 
data  is  improved.  Decreasing  the  number  of 
commands  needed  by  an  RV  lessens  the  amount 
of  information  that  must  be  transmitted. 

•  Decreased  Operator  Workload.  As  an  RV's 
autonomy  increases,  the  number  of  moment-to- 
moment  commands  generated  by  the  operator  to 
command  the  vehicle  is  decreased,  thus  de¬ 
creasing  the  operator  workload.  If  the  work¬ 
load  is  sufficiently  decreased,  the  operator 
can  perform  other  duties  while  at  the  same 
time  maintaining  control  of  the  RV.  Other 
duties  may  include  controlling  additional 
RVs.  This  increases  the  productivity  of  the 
operator,  and  thus  increases  force  effective¬ 
ness  . 

5. 2. 5. 3.  Examples.  To  further  describe  high-level 
commands,  two  examples,  using  vehicle  speed  and  weapon 
usage,  will  be  given. 

•  Vehicle  Speed.  At  the  lowest  level,  the 
speed  of  a  vehicle  is  controlled  by  adjusting 
the  engine  throttle.  This  requires  the  oper¬ 
ator  to  constantly  change  the  throttle  de¬ 
pending  upon  the  vehicle,  road  and  weather 
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conditions . 


A  higher  level  commahd  would  set  the  vehicle 
speed.  It  would  thdh  be  the  job  of  the  RV, 
independent  of  this  human  operator,  to  gener¬ 
ate  the  moment-to-moment  throttle  commands 
needed  to  maintain  the  de&ired  speed.  A 
cruise  control  device,  common  on  commercial 
automobiles,  could  be  mounted  on  ah  RV  and 
could  carry  out  this  higher  level  command. 

Another  high-level  command  might  be  to  tell 
the  RV  to  go  from  point  A  to  point  B  in  the 
shortest  time  possible.  Now  the  RV  would 
attempt  to  maintain  €ft£  highest  speed  pos¬ 
sible  While  taking  ihto  account  the  terrain 
and  weather  conditions  and  the  engine  and 
vehicle  limitations. 

•  Weapon  Usage.  At  the  lowest  level,  the  oper¬ 
ator  would  detect  a  target.  He  would  then 
send  commands  to  position  the  weapon  and  to 
fire  it. 

At  a  higher  level,  the  operator  might  still 
need  to  detect  the  target.  He  could  then  send 
a  command,  "Lock  on  target."  When  the  weapon 
had  autonomously  locked  on  the  target,  the 
operator  could  send  a  command  to  fire. 

At  the  highest  level,  the  operator  could  give 
the  single  command,  ‘'Engage  enemy.”  The  RV 
would  then  autonomously  detect  a  target,  posi¬ 
tion  the  weapon,  and  fire  at  the  target. 

5. 2. 5.4.  Need  for  high-level  commands.  The  principal 
argument  used  against  the  adoption  of  standards  is  that 
they  tend  to  freeze  technology,  and  become  obsolete.  It  is 
imperative  that  the  developer  of  a  standard  take  into 
account  future  requirements  do  that  the  standard  would  not 
become  obsolete. 

With  RVs,  the  trend  is  for  increased  onboard  intelligence. 
Therefore,  the  standard  message  format  developed  in  this 
document  must  include  high-level  control  commands,  as  well 
as  have  the  flexibility  to  add  additional  high-level 
commands  as  they  are  needed. 

5.2.6.  Automated  Functions,  increasing  the  autonomy  of 
RVs  (using  high-level  commands  is  one  method  by  which  to 
reduce  the  bandwidth  requirements  of  robotic  vehicle 
communication  systems.  Another  method  is  to  automate  as 
many  functions  as  possible. 
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An  automated  function  is  one  which  normally  must  be 
performed  by  a  human  operator  but  can  be  done  autonomously. 
It  differs  from  a  high-level  command  in  that  it  needs  no 
operator  supervision  at  all. 

There  are  many  functions  that  have  the  potential  to  be 
automated.  An  example  of  one  is  the  operation  of  a 
vehicle's  bilge  pumps. 

Bilge  pumps  are  turned  on  by  a  vehicle's  crewmember  when 
water  has  entered  the  hull.  The  function  of  turning  on  the 
bilge  pump  could  be  automated  by  putting  water  sensors  in 
appropriate  locations.  Upon  sensing  a  predetermined  amount 
of  water,  the  bilge  pumps  would  automatically  turn  on. 

Also,  the  pumps  would  automatically  turn  off  when  the  water 
has  been  flushed  out.  Automating  the  operation  of  the 
bilge  pumps  would  give  the  RV  operator  one  fewer  function 
to  control  and  would  delete  the  need  to  send  a  control 
command . 

Some  of  the  other  functions  that  are  candidates  for 
automation  include: 

Interior  temperature 

Suspension  height 

Fuel  tank  selector 

Fire  extinguishing  system 

Camera  lens  focus 

5.2.7.  Complete  Control/Status  Listing.  Appendix  B 
contains  the  results  of  this  section. 

5.3.  Representation  of  the  Compiled  Information 
The  control  commands  and  the  status  information  compiled  in 
the  previous  section  can  be  digitally  represented  by  a 
message  format.  Three  different  types  of  message  formats 
are  considered: 

Fixed-length  message  format 

Variable-length  message  format 

Block  message  format 

5.3.1.  Description  of  the  message  formats.  The  three 
types  of  message  formats  are  described  below, 

5. 3. 1.1.  Fixed-length  message  format.  A  fixed-length 
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message  format  is  a  stream  of  parameters  in  a  predetermined 
sequence,.  (See  Figure  5-5. (a))  The  location  of  the 
parameters  within  the  stream  dictates  the  function  being 
controlled  and  the  status  information  being  transferred. 

The  RV  knows  wh^t  to  do  with  each  parameter  because  of  its 
location  in  the  sequence.  No  function  identification  is 
necessary  in  this  type  of  message  format. 

5. 3. 1.2.  Variable -length  message  format.  A  variable- 
length  message  format,  like  a  fixed-length  message  format, 
is  also  a  stream  of  parameters  in  a  predetermined  sequence. 
With  a  variable- length  format,  however,  a  parameter  is  only 
sent  when  it  is  needed. 

Whether  or  not  a  parameter  is  needed  is  depicted  by  a 
"parameter  needed  (PN)"  bit.  (See  Figure  5-5  (b) )  When  the 
PN  bit  is  set  (has  a  value  of  one),  a  parameter  is  needed 
and  will  immediately  follow.  When  the  PN  bit  is  not  set 
(has  a  value  of  zero) ,  a  parameter  is  not  needed  and  thus 
will  not  follow.  The  following  bit  will  instead  be  another 
pN  bit. 

5. 3. 1.3.  Block  message  format.  With  a  block  message 
format/  each  parameter  is  individually  identified.  (See 
Figure  5-5  (c))  Parameters  are  not  part  of  a  data 

packet  with  a  predetermined  parameter  sequence,  as  with  the 
fixed-and-variable  length  message  formats. 

Not  being  part  of  a  sequence,  different  parameters  can  be 
sent  at  different  frequencies.  For  example,  an  RV  being 
remotely  driven  out  to  a  sentry  post  may  require  hundreds 
of  steering  commands,  but  no  weapon  control  commands. 

Because  the  parameters  are  not  transmitted  in  a  prede¬ 
termined  sequence,  they  must  each  be  identified.  This  is 
done  with  a  series  of ' labels. 

The  message  length  is  variable.  When  little  or  no  activity 
is  required,  the  message  length  will  approach  zero  bytes. 

An  RV  performing  a  variety  of  functions  in  a  complex 
environment  will  have  a  long  message  length. 

The  parameter  labels  also  vary  in  length.  Some  messages 
require  more  bits  than  others  to  be  accurately  identified. 

5.3.2.  Analysis  of  the  message  formats. 

5. 3. 2.1.  Fixed-length  message  format.  The  fixed-length 
message  format  offers  two  advantages.  The  first  is  that  no 
bits  are  needed  to  identify,  to* what  application  the 
transmitted  parameters  apply.  All  the  bits  of  data  are 
parameters.  This  makes  for  an  efficient  use  of  the  data 


Steer 


Brake 


Throttle 


Camera 


Gear 


(a)  Fixed  Length  Format 


PN  Steer  I  PN  I  Brake  PN  Throttle 


(b)  Variable  Length  Format 


(c)  Block  Format 


Control  Parameter 


Function 

Identifier 


Figure  5-5.  Candidate  Message  Formats 
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link. 


The  second  advantage  is  the  simplicity  with  which  an  RV  and 
a  control  station  can  handle  the  received  message.  Routing 
the  parameters  to  the  proper  location  is  easily  done  since 
the  parameter  applications  are  predetermined. 

There  are  three  disadvantages  to  using  a  fixed-length 
message  format.  The  first  is  that  the  frequency  with  which 
a  parameter  is  sent  cannot  be  varied.  A  parameter  is  sent 
once  in  every  message.  Even  though  a  parameter  may  not  be 
needed,  it  is  still  transmitted.  This  leads  to  the 
transmission  of  unneeded  parameters. 

The  second  disadvantage  is  that  there  is  no  way  to  order 
the  parameters  by  priority  .  Since  the  parameters  must  be 
sent  in  their  predetermined  sequence,  there  is  no  means  to 
send  a  more  important  parameter  before  a  less  important 
one . 

The  third  disadvantage  is  the  lack  of  flexibility  that  this 
type  of  message  format  offers.  Different  types  of  robotic 
vehicles  require  different  control  commands  and  status 
information  depending  upon  their  configuration  and  the 
mission  they  are  performing.  A  message  format  must  be  able 
to  accommodate  different  requirements  if  it  is  to  become  a 
standard.  The  fixed-length  message  format  does  not  offer 
this  flexibility  since  it  would  need  to  be  altered  for  each 
different  application. 

5. 3. 2. 2.  Variable -length  message  format.  The  advantages 
and  disadvantages  of  the  fixed-length  message  format  also 
apply  to  the  variable-length  message  format,  with  two 
differences.  The  first  is  that  the  variable-length  message 
format  is  more  data  rate  efficient  than  the  fixed-length 
format.  This  is  because  parameters  are  not  transmitted  if 
they  are  not  needed. 

The  second  difference  is  that  there  is  an  increase  in  the 
processing  required  of  the  receiving  entity  when  using  the 
variable-length  format.  The  receiving  entity  must 
determine  if  it  should  or  should  not  route  the  parameters 
to  certain  applications,  depending  on  the  value  of  the 
"parameter  needed"  bit. 

5. 3. 3. 3.  Block  message  format.  There  are  three  advantages 
to  using  a  block  format.  The  first  advantage  is  the 
flexibility  of  this  format.  Functions  can  be  identified 
for  each  vehicle  and  mission  module,  but  only  those 
applicable  to  a  particular  eysjtem  need  to  be  used. 

As  requirements  for  robotic  vehicle  systems  develop  and 
evolve,  new  messages  can  be  added  and  obsolete  ones 
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deleted.  This  will  keep  the  message  format  from  becoming 
obsolete. 

The  second  advantage  is  that  the  parameters  can  be  ordered 
by  priority.  This  is  possible  since  they  are  not  arranged 
in  a  predetermined  sequence. 

The  third  advantage  is  that  messages  are  only  sent  when 
needed,  decreasing  data  rate  requirements. 

There  are  two  disadvantages  to  using  a  block  message 
format.  The  first  is  that  each  parameter  needs  to  be 
identified.  This  can  be  done  with  a  label  two  bytes  in 
length. 

The  second  disadvantage  is  the  burden  put  on  the  receiving 
entity.  Upon  the  receipt  of  data,  it  must  be  processed  to 
determine  what  application  the  parameter  is  for. 

5.3.4.  Comparison.  Table  5-5  summarizes  the  advantages 
and  disadvantages  of  the  three  message  formats  presented  in 
this  chapter. 

As  shown,  the  bandwidth  required  for  each  message  format 
varies  with  the  complexity  of  the  message.  For  a  robotic 
vehicle  system  requiring  few  commands,  the  variable-and 
fixed-length  message  formats  can  operate  over  links 
using  slower  data  rates.  The  block  format  requires  faster 
rates . 

For  a  more  complex  robotic  vehicle  system  requiring  many 
different  commands,  the  block  format  can  use  the  link  with 
the  slowest  data  rate  because  it  only  sends  messages  when 
they  are  needed. 

The  block  format  is  flexible  and  allows  commands  to  be 
ordered  by  priority.  Flexibility  is  extremely  important 
for  a  message  format  that  is  to  be  part  of  an  interface 
standard.  Without  flexibility,  the  standard  will  not 
likely  be  adopted. 

Neither  the  fixed-nor-variable  length  message  formats  offer 
flexibility  or  the  ability  to  order  commands  by  priority. 

A  communication  system  using  a  functional  block  format 
requires  the  most  processing  by  the  receiving  entity.  The 
fixed-length  message  format  requires  the  least  processing, 
and  the  variable-length  format  requires  an  intermediate 
amount . 

The  increased  amount  of  processing  time  and  resources 
required  when  using  a  functional  block  format  is  a  penalty 
to  adopting  this  format.  But  this  penalty  is  negligible 


Table  5-5.  Message  Format  Comparison 


Message 

Format 

Flexible 

Bandwidth 

reaulred' 

Processing 

reouired 

Prioritized 

commands 

Fixed 

Length 

No 

Varies  with 

message 

complexity 

Least 

No 

Variable 

Length 

No 

Varies  with 

message 

complexity 

Medium 

No 

Functional 

Block 

Yes 

Varies  with 

message 

complexity 

Most 

Yes 
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because  of  the  increasing  speed  and  decreasing  cost  of 
computer  equipment. 

These  facts,  plus  the  flexibility  and  the  ability  to  order 
the  messages  by  priority,  make  the  block  format  the  best 
message  format  for  a  robotic  vehicle  communications 
interface  standard. 

5.3.5.  Proposed  Message  Format.  There  are  many  different 
possible  structures  that  a  block  message  format  can  take. 
The  format  proposed  for  robotic  vehicles  is  shown  in  Figure 
5-6.  Appendices  C  and  D  define  the  digital  coding  for  the 
messages . 


5. 3. 5.1.  Field  descriptions.  The  message  length  field  is 
one  byte  in  length  and  describes  the  length  (number  of 
bytes)  of  the  message,  including  the  length  byte  itself. 

The  source  address  field  is  also  one  byte  in  length  and  it 
tells  where  the  message  originated. 

The  message  field  can  be  broken  down  into  multiple 
commands.  Each  command  consists  of: 

-  A  length  field  one  byte  in  length  which  describes  the 
length  (number  of  bytes)  of  the  command,  including  the 
length  byte  itself. 

-  A  block  field  one  byte  in  length.  This  field  is  the 
first  part  of  the  command/status  identifier.  Its  one  byte 
length  makes  it  possible  to  identify  256  (2°)  different 
blocks.  The  blocks  are  the  result  of  the  control  commands 
and  the  status  information  being  classified  according  to 
their  function. 

-  One  or  more  function  fields.  Each  function  field 
consists  of  a  one  byte  function  identifier,  which  is  the 
second  part  of  the  command/status  identifier.  The  one  byte 
length  makes  it  possible  to  identify  256  functions  per 
block.  Where  necessary,  a  parameter  one  or  more  bytes  in 
length  follows.  A  parameter  is  the  actual  control  or  status 
value. 

5. 3. 5. 2.  Parameter  types.  There  are  three  types  of 
parameters  which  can  be  used: 

Numeric  (N) 

Select  (S) 

Proportional  intensity  (PI) 

The  type  of  parameter  associated  with  each  block  is  shown 
in  Appendices  D  and  E. 
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Message 


Figure  5-6,  Command/Status  Message  Format 
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5. 3. 5. 3.  Parameter  representations.  Numeric  parameters 
are  represented  with  binary  encoding.  For  example,  decimal 
71  is  represented  by  0100  0111.  This  is  hexadecimal  47. 

Select  parameters  are  used  when  we  need  to  choose  one  or 
more  options  from  a  group  of  choices. 

Proportional  intensity  parameters  are  used  to  represent 
three  types  of  commands/status: 

Off,  incrementally  increasing  to  full  on. 

Down,  incrementally  rising  to  full  up. 

Straight  ahead,  incrementally  changing  to 
full  left  or  full  right. 

•  Off  to  on  is  represented  by  a  one-byte  param¬ 
eter.  Hexadecimal  00  (binary  0000  0000) 
represents  off.  Hexadecimal  FF  (binary  1111 
1111)  represents  full  on.  All  values  inbe- 
tween  represent  proportional  positions. 

•  Down  to  up  is  represented  by  a  one-byte 
parameter.  Hexadecimal  00  represents  full 
down.  Hexadecimal  FF  represents  full  up. 

All  values  inbetween  represent  proportional 
positions. 

•  Left  to  right  is  represented  by  a  one-byte 
signed  parameter.  Hexadecimal  7F  is  full 
left.  Hexadecimal  00  is  straight  ahead. 

Hexadecimal  FF  is  full  right.  All  values 
inbetween  represent  proportional  positions. 

5. 3. 5. 4.  Message  generation.  Messages  are  generated  using 
the  following  steps: 

Determine  the  block  field  codes  from  Appendices 
D  and  E. 

Get  the  function  field  code  from  Appendices  D 
and  E. 

Append  the  required  parameters. 

Determine  the  message  length  and  the  command 
lengths. 

Enter  numeric  values  into  the  message  format. 

5. 3. 5. 5.  Examples,  Three  examples  are  given  which 
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illustrate  using  Appendices  D  and  E  and  the  message  format 
to  generate  coded  messages  which  represent  control  commands 
and  status  information. 

Example  1.  An  bperAtbf  initiates  th'6  following  commands: 

-  Turn  vehicle  full  right 

-  Engine  at  half  throttle 
•  Turn  on  headlights 

-  Turn  on  the  power  to  the  FLIR 

The  following  chart  is  used  €d  put  the  commands  into  the 
required  message  format: 


Command  Block  Function 


Number 

Message 

Field  Field 

Parameter  Length 

1 

Vehicle  full  right 

03 

01 

FF 

04 

2 

Engine  half  throttle 

01 

03 

40 

04 

3 

Turn  on  headlights 

0E 

01 

03 

4 

Power  to  the  FLIR 

18 

01 

03 

The 

resulting  message,  in  hexadecimal 

values. 

is: 

10  03  04  03  01  FF  04  01 

03  40 

03  0E 

01  03 

18  01 

NOTE:  Source  address  has  arbitrarily  been  chosen  to  be  03. 
Also,  the  above  codes  would  be  put  in  the  SDLC  format  for 
transmission  over  the  data  link. 

Example  2.  An  operator  initiates  the  following  commands: 

-  Engine  at  zero  throttle 

-  Turn  heater  on  t 

-  Turn  air  conditioner  off 

-  Turn  on  bilge  pump 

-  Stop  transmitting  video  from  the  left  and  right 
peripheral  cameras 

-  Begin  transmitting  images  from  the  reconnaissance 
camera  and  the  FLIR 

The  following  chart  is  used’  to  put  the  commands  into  the 
required  message  format: 
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Command 
Number  Message 


Block  Function 

Field  Field  Parameter  Length 


1 

Zero  throttle 

01 

03 

00 

04 

2 

Heater  on 

0D 

03 

&r  osr 

AC  off 

06 

Bilge  pump  on 

09 

3 

Stop  transmission  of 
right  peripheral 
camera  imagery 

Stop  transmission  of 

10 

08 

left  peripheral 

camera  imagery 

06 

Transmit  FLIR  images 
Transmit  reconnais¬ 

OF 

sance  images 

0B 

The  resulting  message,  in  hexadecimal  values,  is: 

11  03  04  01  03  00  05  0D  03  06  09  06  10  08  06  OF  0B 


Example  3.  An  RV's  central  control  unit  initiates  the 
following  status  messages: 

-  Engine  hot 

-  Fuel  low 

-  Interior  temperature  72° 

The  following  chart  is  used  to  put  the  commands  into  the 
required  message  format: 


Command  Block  Function 

Number  Message  Field  Field  Parameter  Length 


1  Engine  hot 

81 

06 

03 

2  Fuel  low 

8B 

02 

03 

3  Interior  temperature 

8D 

01  48 

04 

Message:  0C  03  03  81  06  03 

8B  02 

04  8D  01  48 

5. 3. 5. 6.  Request  for  status.  A  request  for  status  is  made 
by  sending  the  appropriate  status  identifier  from  a  command 
center  to  an  RV.  For  example,  a  request  command  for  the 
RV's  heading  would  have  the  block  field  B0  and  the  function 
identifier  01. 

5. 3. 5. 7.  Room  for  growth.  The  proposed  message  format 
will  only  be  effective  if  it  does  not  hinder  the 
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development  of  new  systems  find  subsystems.  Therefore  it 
must  be  flexible  and  have  rdom  to  grow.  By  using  one  byte 
to  identify  the  message  blogk,  there  are  256  possible 
blocks.  The  current  compilation  of  messages  resulting  from 
the  investigation  described  earlier  produced  62  blocks, 
leaving  ample  room  for  expansion.  Also,  by  using  one  byte 
to  identify  the  functions  in ^ each  block,  there  are  256 
possible  functions.  So  far,  the  most  identified  for  any 
one  block  is  27. 

5.3.6.  Complete  Message.  The  message  format  described  in 
the  previous  sections  will  become  part  of  the  whole  data 
packet  that  is  transferred  between  entities.  The  whole 
packet  also  includes  the  transport  layer  protocol  overhead 
as  well  as  the  data  link  layer  protocol  overhead. 

Figure  5-7.  illustrates  the  entire  data  packet  including 
data  link,  transport,  and  presentation  layer  protocols 
overhead. 

5.4.  Protocol  Testing 

The  proposed  protocols  and  message  format  will  be  imple¬ 
mented  in  TACOM's  Robotic  Combat  Vehicle  program  in  fiscal 
years  1989  and  1990.  This  will  allow  the  protocols  to  be 
tested. 

Also,  TACOM  will  make  the  documentation  available  to  other 
robotic  systems  being  developed  so  that  they  may  evaluate 
the  proposed  protocols  as  well.  This  will  lead  to 
identification  of  any  revisions  or  improvements  required  to 
make  the  protocols  fully  functional. 

By  evaluating  and  testing  communication  protocols  now, 
while  robotic  vehicle  systems  are  still  in  the  testbed 
stage,  an  optimum  set  of  protocols  can  be  available  when 
robotic  vehicles  are  ready  for  full-scale  development. 
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Flag 


Address 


Data 


CRC 


Flag 
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APPENDIX  A 


CONTROL/STATUS  OF  MANNED  MILITARY  VEHICLES 


A-l 


MANNED  VEHICLE  CONTROLS 


Description 
of  function 

Accelerator 

Bilge  pumps  on/off 

Brake 

Defroster  control 

Driver’s  night  vision  viewer 

Driver’s  periscope  wiper 

Engine  accesory 

Engine  shutoff 

Engine  starter 

Engine  starter  (cold  start) 

Fire  suppression 

Fording  control 

Fuel  control 

Fuel  tank  selector 

Garage  toggle 

Gear  selector 

Hazard  warning  light 

High/low  ratio  selector 

Horn 

Infrared  lenses 


Ml 

Abrams 

(heavy) 

X 

X 

X 

X 

X 

X 


X 

X 


M2/M3 

Bradley 

(med) 

X 

X 


X 

X 

X 

X 

X 

X 


HMMWV 

(light) 

X 

X 

X 


X 

X 

X 


X 

X 

X 


Cobra 

(elec) 

X 

X 

X 


X 

X 


X 

X 

X 

X 
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MANNED  VEHIGLE  CONTROLS 


Description 
o-f  -function 

Ml 

M2/M3 

Abrams 

Bradley 

HMMWV 

Cobra 

(heavy) 

(med) 

(light) 

(elec) 

Intercom 

X 

X 

Light  selector 

X 

X 

X 

X 

Master  power 

X 

X 

NBC  system  on /off 

X 

X 

Panel  lights  control 

X 

X 

X 

X 

Parking  brake  release 

X 

X 

Parking  brake  set 

X 

X 

X 

Periscope  adjustment 

X 

Periscope  washer  pump 

X 

Pivot 

X 

X 

X 

Road/ water  toggle 

X 

Service  brake 

X 

X 

Smoke  screen  generator 

X 

X 

Splash  guard  up/down 

X 

Steering 

X 

X 

X 

X 

Steering  wheel  lock  cable 

X 

Tactical  idle 

X 

Throttle  control 

X 

X 

X 

Transfer  case 
Transmission  on/of f 

* 
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MANNED  VEHICLE  CONTROLS 


Descr iption 
o-f  •function 

Turn  indicator 

Water  barrier  release 

Windshield  washer/wiper 


Ml  M2/M3 

Abrams  Bradley  HMMWV 

(heavy)  (med)  (light) 

X  X 

X 

X 


Cobra 

(elec) 

X 
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MANNED  VEHICLE  STATUS 


Description 
of  function 

Ml 

Abrams 

(heavy) 

M2/M3 

Bradley 

(med) 

HMMWV 

(light) 

Cobra 

(elec 

Air  cleaner  clogged  warning 

Alternator  temperature  high 

X 

X 

X 

Back  door  open 

X 

Battery  charge  low 

X 

Bilge  pump  (fwd* rear) 

X 

X 

X 

Brake  master  cyl  fluid  level 

low 

X 

Brake  worn 

X 

Cable  disconnected 

X 

Circuit  breaker  open 

X 

Cold  start  indicator 

X 

X 

Coolant  high  temp  warning 

X 

X 

Coolant  low  level  warning 

X 

X 

Engine  started 

X 

Engine  abort 

X 

Engine  accessary  indicator 

X 

Engine  coolant  temp  gauge 

X 

X 

X 

Engine  hour  meter 

X 

X 

Engine  oil  filter  clogged 

X 

Engine  oil  low 

X 

Engine  oil  pressure  gauge 

X 

If 

X 

X 
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MANNED  VEHICLE  STATUS 


Description 
of  function 

Engine  oil  pressure  warning 
Engine  oil  temperature  high 
Exhaust  temperature 
Fire  detector  sensor 
Fire  ext  bottle  pres  gauge 
Fire  supp  discharge  indicator 
Fire  supp  manual  indicator 
Fuel  (F, 1/2, 1/4, E) 

Fuel  control  -faulty 

Fuel  -filter  clogged  warning 

Fuel  gauge 

Fuel  level  low 

Full  pivot 

Gas  over  temperature 
Headlights  high  beam 
Headlights  low  beam 
Heater  control 
Heater  fan 

Hydraulic  system  malfunction 
Master  caution 


Ml 

Abrams 

(heavy) 

X 

X 


M2/M3 

Bradley 

(med) 

X 


HMMWV 

(light) 

X 


Cobra 

(elec) 

X 

X 

X 
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MANNED  vehicle  status 


Description 
of  -function 

Master  power  indicator 

Master  warning 

NBC  filter  clogged 

NBC  on 

NBC  overheated 
NBC  overpressure 
NBC  system  indicator 
Night  periscope 
Odometer 

Parking  brake  sys  hyd  pres  gauge 

Parking  lights  on 

Parking/service  brake  on 

Ramp  unlock  indicator 

Rear  left  fuel  pump  bad 

Rear  right  fuel  pump  bad 

Road  mode 

STE/ICE  diagnostic  connector 
Slope  indicator 
Smoke  screen  generator  on 
Speedometer 


Ml  M2/M3 

Abrams  Bradley  HMMWV  Cobra 
(heavy)  (med)  (light)  (elec) 

X  X 

r 

X 

X 

X 

X 

X  X 

X 

X  X  X  X 

X  X 


X 

X 


X  X 

X?  X  X  X 


A-8 


MANNED  VEHICLE  STATUS 


Ml 

Description  Abrams 

o-f  -function  (heavy) 

Tachometer  X 

Transmission  damage-inspect  X 

Transmission  gear  selected  X 

Transmission  o-f-f 

Transmission  oil  -filter  clogged  X 

Transmission  oil  low  X 

Transmission  oil  pressure  warning  X 

Transmission  oil  temp  warning  X 

Trip  odometer 

Turn  indicator  lights  X 

Turret  power  indicator 
Turret  seal  pressure  gauge  X 

Voltage  gauge  X 

Water  mode 


M2/M3 

Bradley  HMMWV 
(med)  (light) 


X  X 


Cobra 

(elec) 

X 

X 

X 


X 

X 
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APPENDIX  B 


CONTROL/STATUS  REQUIRED  FOR  ROBOTIC  VEHICLE  SYSTEMS 


B— 1 


B-2 


Controls  Required  for 
Robotic  Vehicle  Systems 


1. 

Power  plant 

9 

2. 

Brakes 

10 

3. 

Steering 

11 

4. 

Transmission 

12 

5. 

Suspension 

13 

6. 

Fording 

14 

7. 

Mobility 

15 

8. 

Fuel 

16 

Turret 

Interior 

Lights 

Electro-optic  Sensors 
Condition  Sensors 
Communications 
Inertial  Navigation  System 
Mission  module 


B-3 


required  controls 


1.  Power  plant 
Start 

Cold  start 
Kill 

Throttle 

Idle  set 

Tactical  idle 

Fuel  delivery 

Cruise  control  (CC) 

CC  Set 
CC  Resume 
CC  Accelerate 
CC  Decelerate 
CC  Coast 

Electric  current  * 

2.  Brakes 

Brake 

Parking  brake  set/unset 
Service  brake  set/unset 

3.  Steering 

Steer 

Radius  of  turn 
Heading 

Directional  movement 

*  For  battery  power  plant 
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REQUIRED  CONTROLS 


4.  Transmission 

Automatic  gear  select 

Park 

Reverse 

Neutral 

Drive 

Drive,  L 

Pivot 

Tow 

Manual  Gear  select 

Transfer  case 

High 

Low 

Neutral 
Wheel  drive 

5.  Suspension 

Air  shock  height 

Hydroneumat ic  suspension  level  control 

6.  Fording 

Road/water  propulsion 
Splash  guard  up/down 
Water  barrier  release  level 
Exhaust  pipe  rise 

7.  Mobility 

Emergency  stop 
Velocity 

Move  to  grid  coordinates 

Pivot 

CARD  mode 


Autonomous  raad  following  mode 


REQUIRED  CONTROLS 


8.  Fuel 

Fuel  tank  selector 
Fuel  filler  lock/unlock 
Fuel  filler  open/close 

9.  Turret 

Power 

Enable  (turret  travel  lock) 
Slew 

Elevation 

10.  Interior 

Defroster 

Heater 

Air  Conditioner 
Temperature  setting 
NBC  system  On/Off 
Bilge  pumps,  front 
Bilge  pumps,  rear 
Fire  supression 
Horn 

Vent  open/close 
Vent  fan 
Wipers 

Heated  glass 

* 

Doors  lock/unloek 
Windows  up/down 

B-6 


REQUIRED  CONTROLS 


11.  Lights 

Head  lights 

High  beam 
Low  Beam 

Parking  lights 

Turn  indicator 

Left 

Right 

Hazard  lights 
Blackout  lights 
Interior  lights 
Exterior  flood  lights 
Exterior  spot  light 
Fog  lights 
Back-up  lights 

12.  Electro-optic  Sensors 

Sensor  switch 

Video 

Radar 

IR  Thermal  imaging  system 
Image  intensifier 
Laser  ranger 

Video  camera  selector 

Forward 

Stereo 

Rear 

Sensor  control 

Azimuth 

Elevation 

Tilt 

Scan  rate 
Sector  size 
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REQUIRED  CONTROLS 


12.  Electro-optic  Sensors  (cont) 

Sensor  control 

B  &  W/Color 

Contrast 

Iris  F/B  switch 

Shutter  speed 

Zoom 

Focus 

Home 

Wipers 

De-icer 

Convergence 

Hot/white 

Logic  select 

Field  of  view 


13.  Condition  sensors 

Radar  detector 
Magnetic  field  detector 
Motion  detector 
Frequency  detector 
Light  detector 
Sonic  detector 
NBC  detector 
Noise  detector 
Rain  detector 
Snow  detector 

14.  Communications 

System  choice 
RF 

Fiber  optic 

Microwave 

Laser 
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REQUIRED  CONTROLS 


14.  Communications  (cont) 

Radio  options 

Frequency  select 
AJ  techniques 
Transmitting  power 

Fiber  optic  options 

Antenna  control 

Elevation 

Azimuth 

Polarization 

Auto-track 

15.  inertial  navigation  system 

Initialize 

Reset 

16.  Mission  module 

Reconnaissance  module 

Mine  field  breacher 

Weapons  package 

CARD  module 

Jamming  device 

Smoke  generator 

Others  to  be  determined 


B-9 


Status  Required  for 
Robotic  Vehicle  Systems 


1. 

Power  plant 

10 

2. 

Brakes 

11 

3. 

Steering 

12 

4. 

Transmission 

13 

5. 

Suspension 

14 

6. 

Fording 

15 

7. 

Mobility 

16 

8. 

Fuel 

17 

9, 

Turret 

18 

Interior 

Lights 

Electro-optic  Sensors 
Condition  Sensors 
Communications 
Inertial  Navigation  Data 
Mission  modules 
Circuit  breaker  faults 
Exterior 


B-10 


f 


REQUIRED  STATUS 


1.  Power  plant 

Running/started 

Tachometer 

Coolant 

Temperature  gauge 

Low  level 

High  temperature 

Oil 

Pressure  gauge 
Pressure  low 
Level  low 
Temperature  high 

Alternator 

Temperature  high 
Not  functioning 

Cold  start  indicator 

Exhaust  temp  high 

Battery  charge  low 

Voltage  gauge 

Air  cleaner  clogged 

Oil  filter  clogged 

Fuel  filter  clogged 

Fuel  pump  bad 

Fuel  control  faulty 

Hour  meter 

Throttle  feedback 

Microphone  in  engine  compartment  On/Off 


B-ll 


REQUIRED  STATUS 


2.  Brakes 

*•  f.  -*f> 

Brake  feedback 
Brakes  worn 

Master  cylinder  fluid  level  low 
Brake  line  pressure  gauge 
Low  brake  air 
Brakes  nonfunctional 
Parking  brake 
On/Off 

Hydraulic  pressure  gauge 


3.  Steering 

Steering  feedback 

4.  Transmission 

Automatic  transmission  gear  selected 

Park 
Reverse 
Neutral 
Drive 
Drive,  L 
Drive,  H 
Pivot 
Tow 

Manual  transmission  gear  selected 

Transfer  case 
High 
Low 

Neutral 
Wheel  drive 
Transmission  fluid 

V 

Filter  clogged 
Pressure  warning 


B-12 


REQUIRED  STATUS 


4.  Transmission  (cont) 

Temperature  warning 

Level  low 

Damaged 

Shift  gear  indicator 

5.  Suspension 

Air  shock  height 

Hydroneumat ic  suspension  level 

6.  Fording 

River  depth 

River  current  speed 

Road/water  propulsion 

7.  Mobility 

8.  Fuel 

Fuel  gauge 
Fuel  low 

Fuel  temperature  high 

Fuel  filler  cover  on/off,  lock/unlock 

Fuel  leak  alarm 

Instantaneous  MPG 

Battery  powerpack  charge  level 

9.  Turret 

Power 

Seal  pressure  gauge 
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REQUIRED  STATUS 


Interior 

Vehicle  interior  temperature 
NBC  system 
On/Off 

Filter  clogged 
System  overheated 
System  overpressure 

Bilge  pump,  frofl’fc 

Bilge  pump,  rear 

Fire  supression 

Detector 

Discharge  indicator  t 
Extinguisher  bottle  pressure  gauge 

Wipers  on/off 

Door  lock/unlock 

Windows  up/down 

Vent  open/close 

Vent  fan  on/off 

Cabin  pressure 

Moisture  detector  alarm/level  meter 

Door/hatch  ajar 

Heater  on/off 

Air  conditioner  on/off 

Absorbed  power 

Lights 

Head  lights 

High  beam 
Low  beam 

Parking  lights 

B-14 


REQUIRED  STATUS 


11.  Lights  (cont) 

Turn  indicators 
Hazard  lights 
Blackout  lights 
Interior  lights 
Exterior  flood  lights 
Exterior  spot  lights 
Fog  lights 
Back-up  lights 
Engine  compartment  lights 
Bulb  burned  out 

12.  Electro-optic  sensors 

Sensor  switch 

Video 

Radar 

IR  Thermal  imaging  system 
Image  intensifier 
Laser  ranger 

Video  camera  selector 

Forward 

Stereo 

Rear 

Sensor  control 

Scan  rate 
Sector  size 
B  &  W/Color 
Iris  F/B  switch 
Shutter  speed 
Wipers 
Convergence 
Hot/white 
Logic  select 
Field  of  view 


B-15 


REQUIRED  STATUS 


Condition  sensors 
Radar  detected 
Magnetic  field  detected 
Motion  detected 
Frequency  detected 
Light  detected 
Sound  detected 
NBC  detected 
Noise  detected 
Rain  detected 
Snow  detected 


Communciations 
System  choice 
RF 

Fiber  optics 
Microwave 

Radio  options 

Frequency  selected 
AJ  technique 
Transmitting  power 

F.O.  status 

Cable  used 
Cable  left 
Cable  cut 

Antenna  *' 

Polarization 
Auto-track  on 
B-16 


REQUIRED  ST. Vi' US 

15.  Inertial  navigation  system  data 

Head ing 

Altitude 

Roll 

Pitch 

Yaw 

Roll  limit  warning 
Pitch  limit  warning 
Slope  indicator 
Speedometer 
Odometer 
Trip  odometer 
Doppler  speed 
Wheel  count  speed 
UTM  coordinates 
Latitude 
Long i tude 

16.  Mission  modules 

Reconnaissance  module 

Mine  field  breacher 

Weapons  package 

CARD  module 

Jamming  device 

Smoke  generator 

Others  to  be  determined 
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REQUIRED  STATUS 


17.  Circuit  Breaker  Faults 

Master 
Light 
Ignition 
Brake  boost 

18.  Exterior 

Vehicle  hit 
Track  off 

Exterior  temperature 
Audio  sensors  (microphone) 
Tire  flat 

Intrusion  detection  system 


B-18 


APPENDIX  C 


CONTROL  COMMAND  CODING 


C-2 


RCC  TO  RV  CONTROL  COMMAND  CODING 


Function/status 

Block 

Function 

Description 

Field 

Field 

power  plant 

01 

Start 

01 

Kill 

02 

Throttle 

03 

Cold  start 

04 

Tactical  idle  on 

05 

Tactical  idle  off 

06 

Idle  set 

07 

Fuel  turn  on 

09 

Fuel  shut  off 

0A 

Cruise  control  set 

0B 

Cruise  control  resume 

0C 

Cruise  control  accelerate 

0D 

Cruise  control  decelerate 

0E 

Cruise  control  coast 

0F 

Electric  current  flow 

10 

brakes 

02 

ii c  ake 

01 

Parking  brake  set 

02 

Parking  brake  unset 

03 

Service  brake  set 

04 

Service  brake  unset 

05 

Steering 

03 

Steer 

01 

Radius  of  turn 

02 

Heading 

03 

Directional  movement 

04 

Automatic  transmission  04 

Park 

Reverse 

Neutral 

Drive 

Drive,  L 

Drive,  H 

Pivot 

Tow 

Manual  transmission  05 

Reverse 

First 

Second 

Third 


Pa  t a me 
Field 


PI 


PI 


PI 


PI 


PI 

N 

N 

N 

S 

01 

02 

03 

04 

05 

06 

07 

08 

S 

00 

01 

02 

03 
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CONTROL  COMMAND  CODING 


Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Fourth 

04 

Fifth 

05 

Transfer  case 

06 

S 

Wheel  drive 

07 

S 

Suspension 

m 

Air  shock  height 

01 

PI 

Suspension  height 

02 

PI 

Fording 

09 

Road  propulsion 

01 

Water  propulsion 

02 

Splash  guard  up 

03 

Splash  guard  down 

04 

Water  barrier  set 

05 

Water  barrier  release 

06 

Exhaust  pipe  rise 

07 

Exhaust  pipe  lower 

08 

Mobility 

0A 

Emergency  stop 

01 

Velocity 

02 

N 

Grid  coordinates 

03 

N 

Pivot  left 

04 

PI 

Pivot  right 

05 

PI 

CARD  mode,  enter 

11 

CARD  mode,  exit 

12 

CARD  command  identifier 

13 

Autonomous  road  following. 

on 

15 

Autonomous  road  following. 

off 

16 

Fuel 

0B 

Fuel  tank  A 

01 

Fuel  tank  B 

02 

Fuel  filler  lock 

03 

Fuel  filler  unlock 

04 

Fuel  filler  open 

05 

Fuel  filler  close 

06 

Turret 

«C 

Power  on 

01 

Power  off 

p 

02 

Enable 

03 

Disable 

04 

Sl4w 

05 

PI 
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CONTROL  COMMAND  CODING 


Function/status 


Description 


Block  Function  Parameter 

Field  Field  Field 


Elevation 


06  PI 


Interior 

0D 

Defroster  on 

01 

Defroster  off 

02 

Heater  on 

03 

Heater  off 

04 

Air  conditioner  on 

05 

Air  conditioner  off 

06 

NBC  system  on 

07 

NBC  system  off 

08 

Bilge  pumps,  front,  on 

09 

Bilge  pumps,  front,  off 

0A 

Bilge  pumps,  rear,  on 

0B 

Bilge  pumps,  rear,  off 

0C 

Fire  suppression  on 

0D 

Fire  suppression  off 

0E 

Vent  open 

11 

Vent  close 

12 

Vent  fan  on 

13 

Vent  fan  off 

14 

Wipers  on 

15 

Wipers  off 

16 

Heated  glass  on 

17 

Heated  glass  off 

18 

Doors  lock 

19 

Doors  unlock 

1A 

Temperature  setting 

20 

Horn 

21 

Windows  up/down 

22 

N 

PI 


Lights  0E 

Head  lights  on  01 

Head  lights  off  02 

High  beam  on  03 

High  beam  off  04 

Parking  lights  on  05 

Parking  lights  off  06 

Right  turn  indicator  07 

Left  turn  indicator  08 

Hazard  lights  on  09 

Hazard  lights  off  0A 

Blackout  lights  on  0B 

Blackout  lights  off  0C 

Interior  lights  0D 

Fog  lights  on  0E 

Fog  lights  off  0F 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Back-up  lights  on 

.  ..... 

-10 

Back-up  lights  off 

11 

Exterior  flood  lights 

12 

Spot  light  on 

'  ....  ‘  ■  ... 

13 

Spot  light  off 

14 

Spot  light  elevation 

15 

PI 

Spot  light  azimuth  • 

16 

PI 

Spot  light  tilt 

17 

PI 

Electro-optic  Sensor 

Image  Transmit  Select 

10 

S 

Video,  forward,  transmit 

01 

Video,  forward,  do  not  transmit 

02 

Video,  Stereo,  transmit 

03 

Video,  Stereo,  do  not  transmit 

04 

Video,  left  peripheral. 

transmit 

05 

Video,  left  peripheral. 

do  not  transmit 

06 

Video,  right  peripheral, 

transmit 

07 

Video,  right  peripheral. 

do  not  transmit 

08 

Video,  rear,  transmit 

09 

Video,  rear,  do  not  transmit 

0A 

Video,  reconnaissance,  transmit 

0B 

Video,  reconnaissance,  do  not  transmit 

0C 

Driver's  thermal  viewer 

(DTV) ,  transmit 

0D 

Driver's  thermal  viewer 

(DTV),  do  not 

transmit 

0E 

Forward  looking  infrared 

(FLIR) ,  transmit 

0F 

Forward  looking  infrared 

(FLIR),  do  not  transmit  10 

Radar,  transmit 

11 

Radar,  do  not  transmit 

12 

Laser,  transmit 

13 

Laser,  do  not  transmit 

14 

Video,  forward -  - 

11 

Power  on 

••• 

01 

Power  off 

02 

’  -  •  •  • 

Slew 

03 

PI 

Elevation 

04 

PI 

Tilt 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

07 

N 

De-icer  on 

08 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

• 

0B 

Contrast 

0C 

PI 

Iris  adjust 

.  .V"  • 

0D 

PI 

Shutter  speed 

0E 

K 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Zoom 

0F 

PI 

Focus 

10 

PI 

Home 

11 

Convergence 

12 

PI 

Video,  Stereo 

12 

Power  on 

01. 

i 

Power  off 

02 

Slew 

03 

PI 

Elevation 

04 

PI 

Tilt 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

07 

N 

De-icer  on 

08 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

PI 

Iris  adjust 

0D 

PI 

Shutter  speed 

0E 

N 

Zoom 

0F 

PI 

Focus 

10 

PI 

Home 

11 

Convergence 

12 

PI 

Video,  left  peripheral 

13 

Power  on 

01 

Power  off 

02 

Slew 

03 

PI 

Elevation 

04 

PI 

Tilt 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

07 

N 

De-icer  on 

08 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

PI 

Iris  adjust 

0D 

PI 

Shutter  speed 

0E 

N 

Zoom 

0F 

PI 

Focus 

10 

PI 

Home 

11 

Convergence 

12 

PI 

Video,  right  peripheral 

14 

Power  on 

01 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Power  off 

02 

Slew 

03 

PI 

Elevation 

04 

PI 

Tilt 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

07 

N 

De-icer  on 

08 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

PI 

Iris  adjust 

0D 

PI 

Shutter  speed 

0E 

N 

Zoom 

0F 

PI 

Focus 

10 

PI 

Home 

11 

Convergence 

12 

PI 

Video,  rear 

15 

Power  on 

01 

Power  off 

02 

Slew 

03  - . 

PI 

Elevation 

04 

PI 

Tilt 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

07 

N 

De-icer  on 

08 

De-icer  off 

_ 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

PI 

Iris  adjust 

0D 

PI 

Shutter  speed 

0E 

N 

Zoom 

'  .  “1  "  •'  ‘V- .  • 

0F 

PI 

Focus 

10 

PI 

Home  . 

11 

Convergence 

12 

Video,  reconnaissance 

16 

Power  on 

01 

Power  off 

02 

Slew 

. 

03 

PI 

Elevation 

04 

PI 

Tilt 

.. .  ■  ■■  :  . 

05 

PI 

Scan  rate 

06 

N 

Sector  size 

0 7 

N 

De-icer  on 

..  vO.  ■'■■■■ 

08 
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Function/status 

Block 

Function 

Description 

Field 

Field 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

Iris  adjust 

0D 

Shutter  speed 

0E 

Zoom 

0F 

Focus 

10 

Home 

11 

Convergence 

12 

Driver's  thermal  viewer 

(DTV)  17 

Power  on 

01 

Power  off 

02 

Slew 

03 

Elevation 

04 

Tilt 

05 

Scan  rate 

06 

Sector  size 

07 

De-icer  on 

08 

De-icer  off 

09 

Wipers  on 

0A 

Wipers  off 

0B 

Contrast 

0C 

Iris  adjust 

0D 

Shutter  speed 

0E 

Zoom 

0F 

Focus 

10 

Home 

11 

Convergence 

12 

Stand  by 

13 

Thermal  hot 

14 

Thermal  cold 

15 

Forward  looking  infrared 

(FLIR)  18 

Power  on 

01 

Power  off 

02 

Slew 

03 

Elevation 

04 

Tilt 

05 

Scan  rate 

06 

Sector  size 

07 

De-icer  on 

08 

De-icer  off 

09 

Contrast 

0C 

Zoom 

0F 

Focus 

10 
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Parameter 

Field 


PI 

PI 

N 

PI 

PI 

PI 


PI 

PI 

PI 

N 

N 


PI 

PI 

N 

PI 

PI 

PI 


PI 

PI 

PI 

N 

N 


PI 

PI 

PI 


CONTROL  COMMAND  CODING 


Function/status 

Description 


Home 

Flir  thermal  level 
Flir  thermal  gain 
Flir  focus 
Flir  contrast 

Conditions  Sensors  •  ' 

Radar  detector  on 

Radar  detector  off 

Magnetic  field  detector  on 

Magnetic  field  detector  off 

Motion  detector  on 

Motion  detector  off 

Frequency  detector  on 

Frequency  detector  off 

Light  detector  on 

Light  detector  off 

Sonic  detector  on 

Sonic  detector  off 

NBC  detector  on 

NBC  detector  off 

Noise  detector  on 

Noise  detector  off 

Rain  detector  on 

Rain  detector  off 

Snow  detector  on 

Snow  detector  off 

VHP  radio 
Power  on 
Power  off 
Frequency  select 
Radio  transmitting  power 
Antenna  azimuth 
Antenna  elevation 
Antenna  polarization 
Antenna  auto-track  on 
Antenna  auto-track  off 


Microwave  radio 
Power  on 
Power  off 
Frequency  select 
Radio  transmitting  power 
Antenna  azimuth  I;  ' 

Antenna  elevation 
Antenna  polarization 


Block  Function  parameter 

Field  Field  Field 


01 

02 

03 

N 

04 

PI 

05 

PI 

06 

PI 

07 

S 

08 

09 

V.  ••••  • 

01 

CIO 

:c>  ' v. . 

v  Z 

03 

N 

'■r  A-?  s. 

04 

PI 

05 

PI 

0$ 

PI 

'  w  •  • 

07  . 

S 

CONTROL  COMMAND  CODING 


Function/status 
oescr i ption 

Block 

Field 

Function 

Field 

Par a mete 

Field 

Antenna  auto-track  on 
Antenna  auto-track  off 

08 

09 

Fiber  optic  link 

23 

I. nsec  link 

24 

Inertial  navigation  system 

In i tialize 

Reset 

30 

01 

02 

TBD 

Mission  module  platform 

40 

C-ll 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Power  plant 

81 

Engine  running 

01 

Engine  not  running 

02 

Tachometer 

03 

N 

Coolant  temperature  gauge 

04 

N 

Coolant  level  low 

05 

Coolant  temperature  high 

06 

Oil  pressure  gauge 

07 

N 

Oil  pressure  low 

08 

Oil  level  low 

09 

Oil  temperature  high 

0A 

Oil  filter  clogged 

0B 

Alternator  temperature  high 

0C 

Alternator  not  functioning 

0D 

Cold  start  indicator 

0E 

Exhaust  temperature  high 

0F 

Battery  charge  low 

10 

Voltage  gauge 

11 

N 

Air  cleaner  clogged 

12 

Fuel  filter  clogged 

13 

Fuel  pump  bad 

14 

Hour  meter 

15 

N 

Throttle  feedback 

16 

PI 

Engine  microphone  on 

17 

Engine  microphone  off 

18 

Brakes 

82 

Brake 

01 

PI 

Brakes  worn 

02 

Master  cylinder  fluid 

level  low 

03 

Brake  line  pressure  gauge 

04 

N 

Low  brake  air 

05 

Brakes  nonfunctional 

06 

Parking  brake  set 

07 

Parking  brake  hydraulic 

pressure  gauge 

08 

N 

Steering 

83 

Steering  feedback 

01 

PI 

Automatic  transmission  gear 

84 

S 

Park 

01 

Reverse 

02 

Neutral 

03 
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Function/status 

Description 

Fuel  temperature  high 
Fuel  filler  cover  off 
Fuel  filler  cover  unlocked 
Fuel  leak 
Instantaneous  MPG 
Battery  power  pack  charge 
level 

Turret 

Power 

Seal  pressure  gauge 

Interior 

Temperature 

NBC  system  on 

NBC  filter  clogged 

NBC  system  overheated 

NBC  system  over  pressure 

Front  bilge  pump  on 

Rear  bilge  pump  on 

Fire  detected 

Fire  supression  discharged 
Fire  extinguisher  bottle 
pressure  gauge 
Wipers  on 
Doors  unlocked 
Windows  down 
Vent  open 
Vent  fan  on 
Cabin  pressure 
Moisture  level  high 
Door/hatch  ajar 
Heater  on 

Air  conditioner  on 
Absorbed  power 

Lights 

Head  lights  low  beam 
Head  lights  high  beam 
Parking  lights 
Left  turn  indicator 
Right  turn  indicator 
Hazard  lights 
Blackout  lights 
Interior  light,  front 
Interior  light,  middle 
Interior  light,  back 


Block  Function  Parameter 

Field  Field  Field 

03 

04 

05 

06 

07  N 

08  N 

8C 

01 

02  N 

8D 

01  N 

02 
03 
04 
05 
06 
07 
08 


0A  N 

0B 

0C 

0D 

0E 

0F 

10  N 

11 
12 

13 

14 

15  N 
8E 

01 

02 

03 

04 

05 

06 

07 

08 

09 

0A 
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Function/status 

Description 

Exterior  flood  light 
Exterior  spot  light 
Fog  lights 
Back-up  lights 
Engine  compartment  light 
Bulb(s)  burned  out 


Block  Function  Parameter 

Field  Field  Field 

0B 

0C 

0D 

0E 

0F 

10  S 


Electro-optic  Sensor 

Image  Transmit  Select  90  S 

Video,  forward,  transmitting  01 

Video,  forward,  not  transmitting  02 

Video,  Stereo,  transmitting  03 

Video,  Stereo,  not  transmitting  04 

Video,  left  peripheral,  transmitting  05 

Video,  left  peripheral,  not  transmitting  06 

Video,  right  peripheral,  transmitting  07 

Video,  right  peripheral,  not  transmitting  08 

rear,  transmitting  09 

rear,  not  transmitting  0A 

reconnaissance,  transmitting  0B 

reconnaissance,  not  transmitting  0C 

thermal  viewer  (DTV) ,  transmitting  0D 

thermal  viewer  (DTV) ,  not  transmitting  0E 

0F 


Video  , 

Video, 

Video , 

Video, 

Driver's 
Driver ' s 
Forward  looking  infrared 
Forward  looking  infrared 
Radar,  transmitting 
Radar,  not  transmitting 
Laser,  transmitting 
Laser,  not  transmitting 

Video,  forward 
Power  on 
Power  off 
Scan  rate 
Sector  size 
Shutter  speed 

Video,  Stereo 
Power  on 
Power  off 
Scan  rate 
Sector  size 
Shutter  speed 

Video,  left  peripheral 
Power  on 
Power  off 


(FLIR) ,  transmitting 
(FLlR) ,  not  transmitting  10 

11 

12 

13 

14 


91 


92 


93 


01 

02 

06 

07 

0E 


01 

02 

06 

07 

0E 


01 

02 


N 

N 

N 


N 

N 

N 


D-6 


RV  TO  RCC  STATUS  INFORMATION  CODING 


Function/status 

Block 

Function 

Description 

Field 

Field 

Scan  rate 

06 

Sector  size 

07 

Shutter  speed 

0E 

Video,  right  peripheral 

94 

Power  on 

01 

Power  off 

02 

Scan  rate 

06 

Sector  size 

07 

Shutter  speed 

0E 

Video,  rear 

95 

Power  on 

01 

Power  off 

02 

Scan  rate 

06 

Sector  size 

07 

Shutter  speed 

0E 

Video,  reconnaissance 

96 

Power  on 

01 

Power  off 

02 

Scan  rate 

06 

Sector  size 

07 

Shutter  speed 

0  E 

Driver's  thermal  viewer 

(DTV)  97 

Power  on 

01 

Power  off 

02 

Scan  rate 

06 

Sector  size 

07 

Stand  by 

10 

Thermal  hot 

14 

Thermal  cold 

15 

Forward  looking  infrared 

(FLIR)  98 

Power  on 

01 

Power  off 

02 

Scan  rate 

06 

Sector  size 

07 

FLIR  thermal  level 

13 

FLIR  thermal  gain 

14 

FLIR  focus 

15 

FLIR  contrast 

16 

Condition  sensors 

A0 

Radar  detected 

D-7 

01 

Parameter 

Field 

N 

N 

N 


N 

N 

N 


N 

N 

N 


N 

N 

N 


N 

N 


N 

N 

PI 

PI 

PI 

PI 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Magnetic  field  detected 

02 

Motion  detected 

03 

Frequency  detected 

04 

Light  detected 

05 

Sound  detected 

06 

NBC  detected 

07 

Rain  detected 

08 

Snow  detected 

09 

VHF  radio 

A1 

' 

Power  on 

01 

Power  off 

02 

Frequency  select 

03 

N 

Radio  transmitting  power 

04 

PI 

Antenna  azimuth 

05 

PI 

Antenna  elevation 

06 

PI 

Antenna  polarization 

07 

S 

Antenna  auto-track  on 

08 

Antenna  auto-track  off 

09 

Microwave  radio 

A2 

Power  on 

01 

Power  off 

02 

Frequency  select 

03 

N 

Radio  transmitting  power 

04 

PI 

Antenna  azimuth 

05 

PI 

Antenna  elevation 

06 

PI 

Antenna  polarization 

07 

S 

Antenna  auto-track  on 

08 

Antenna  auto-track  off 

09 

Fiber  optic  link 

A3 

Fiber  optic  cable  cut 

02 

Fiber  optic  cable  left  on 

spool 

03 

N 

Fiber  optic  cable  dispensed 

04 

N 

Laser  link 

A4 

Navigation 

B0 

Heading 

01 

N 

Altitude 

02 

N 

Roll 

03 

N 

Pitch 

04 

N 

Yaw 

05 

N 

Roll  limit  warning 

06 

Pitch  limit  warning 

07 

Slope  indicator 

08 

N 
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Function/status 

Block 

Function 

Parameter 

Description 

Field 

Field 

Field 

Speedometer 

09 

N 

Od ometer 

0A 

N 

Trip  odometer 

0B 

N 

Doppler  speed 

0C 

N 

Wheel  count  speed 

0D 

N 

UTM  coordinates 

0E 

N 

Latitude 

0F 

N 

Longitude 

10 

N 

Mission  Modules  platform 

C  0 

Circuit  Breaker  Faults 

D0 

Master 

01 

Light 

02 

Ignition 

03 

Brake  boost 

04 

Exterior 

E0 

Vehicle  hit 

01 

Track  off 

02 

Exterior  temperature 

03 

N 

Tire  flat 

04 

Intrusion  detection 

05 
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Redstone  Arsenal,  AL  35898 

Contender 

U.S.  Army  Communications- Electronics  Command 
ATTN:  AMSEL-RD-C3- IS  (Saganowich) 

Fort  Monmouth,  MJ  07703 

Commander 

U.S.  Army  Tank-Automotive  Command 
ATTN:  AMSTA-TD  (Schmitz) 

Warren,  MI  48397-5000 

Advanced  Decision  Systems 
ATTN:  Marcel  Schoppers 
1500  Plymouth  Street 
Mountain  View,  California  94943 
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National  Bureau  of  Standards 
ATTN:  Mr.  Harry  Scott 
Building  220,  Roan  B124 
270  Quince  Orchard  Road 
Gaithersburg,  MD  20899 

Cotmander 

U.S.  Army  Human  Engineering  Labs 
ATTN:  SLCHE-CS  (Chuck  Shoemaker) 

Aberdeen  Proving  Grounds,  MD  21005-5001 

U.S.  Army  TCE  &  FLW 

ATTN:  ATZT-CD  (Dr.  Bob  Sickler) 

Fort  Leonardwood,  MO  65473-5000 

Kaman  Sciences 
ATTN:  Mr.  Kieth  Stokes 
P.0.  Box  7463 

Colorado  Springs,  Colorado  80933-7463 
U.S.  Army  Armor  Center 

ATTN:  ATSB-CD-SD  (Captain  Dennis  Szydlowski) 
Fort  Knox,  KY  40121 

Royal  Armament  R&D  Establishment  (Vehicle  Dept) 

ATTN:  John  Tindle 

Chobham  Lane,  Chertsey 

Surrey,  KT16  OEE 

England 

Vectran  Corporation 
ATTN:  Mr.  Tom  Wilson 
261  Kappa  Drive 

Pittsburgh,  Pennsylvania  15238 

FMC  Corporation 

Central  Engineering  Labs 

ATTN:  Yue  Min  Wong 

1205  Coleman  Avenue  Box  580 

Santa  Clara,  California  95052 

International  Microwave  Systems  Corporation 
ATTN:  Mr.  Mike  Young 
2416  Our  Country  Road 
Escondio,  California  92025 

Headquarters,  Department  of  the  Army 
ATTN:  SARD-TR  (Bruce  Zimmerman) 

Washington,  D.C.  20310 
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Copies 

Director  1 

AMSAA 

ATTN:  AMXSY-MP  (Mr.  Cohen) 

Aberdeen  Proving  Ground,  MD  21005-5071 
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